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EVALUATION 


One  goal  of  Software  Engineering  Tools  and  Methods,  a  subthrust  of  TPO-5 
Software  Cost  Reduction,  is  the  development  of  automated  tools  for  use  in 
the  production,  testing,  and  maintenance  of  Air  Force  software.  This  effort 
was  undertaken  in  response  to  that  goal. 

The  objective  of  the  effort  was  to  develop  a  prototype  software  system  for 
formally  verifying  microcode.  The  use  of  microcode  (firmware)  to  implement 
computer  instruction  sets,  rather  than  hard  wiring,  is  a  recent  development 
in  computer  technology.  Hardware  diagnostics  do  not  fulfill  testing 
requirements  for  these  computers. 

Formal  proof-of-correctness  techniques,  previously  developed,  were  applied 
to  develop  a  system  for  "proving"  microcode  correctness.  These  techniques 
were  developed  for  software  written  in  high  order  languages.  This  effort 
is  significant  in  that  it  is  the  first  application  of  the  techniques  on 
assembly  or  micro  level  software. 

Development  of  the  system  was  guided  by  problems  encountered  in  attempting 
to  verify  the  microcoded  instruction  set  of  the  SAMSO  Fault  Tolerant  Space 
Computer  (FTSC).  This  provided  a  practical  problem  to  demonstrate  the 
usefulness  of  the  system.  Verification  of  the  complete  FTSC  instruction 
set  will  be  completed  in  a  follow-on  effort  sponsored  by  SAMSO. 


DONALD  F.  ROBERTS 
Project  Engineer 
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TIil*  qoal  of  the  microcode  verification  project  at  ISI  is  to  develop  both  the  theory  and 
tho  tools  for  verification  of  microcode.  While  some  prior  work  has  been  done  in  this  area, 
notably  [Patterson  77,  Birman  &  Joyner  76],  the  field  was  (and  is)  far  from  closed. 
Problems  exist  at  every  level,  from  fundamental  questions  of  theory  through  questions  of 
strategies  of  system  design  to  problems  of  integration  with  other  software  engineering 
tools  and  education  of  users.  Our  strategy  has  been  to  concentrate  on  developing  a 
working  system,  letting  the  theoretical  issues  emerge— sometimes  painfully— ’amid  system 
development.  We  have  tried  to  delay  overall  consideration  of  the  human  engineering 
questions,  but  have  been  forced  to  consider  some  of  these  when  it  became  too  difficult 
to  use  our  own  systom  without  improving  the  interface. 

To  establish  a  focus  for  the  project  and  provide  a  source  of  examples,  we  selected  a 
particular  computer,  tho  Fault-Tolerant  Spaceborne  Computer  (FTSC),  under  development 
by  Raytheon  for  tho  Space  and  Missile  Systems  Organization  (SAMSO)  of  the  Air  Force. 
The  l-TSC  has  a  number  of  unusual  features  related  to  its  design  goal  for  a  five-year 
maintenance-free  survival  in  space.  These  features  appear  primarily  at  the  hardware 
level  and  in  tho  operating  system,  however,  not  in  the  architecture  seen  or  implemented 
by  tho  microcode.  At  tho  machine  languago  level,  the  programmer  sees  a  32-bit  machine 
with  64  K  of  memory,  8  general  purpose  registers  and  the  usual  types  of  Instructions.  At 
tho  microcode  lovel,  the  machine  is  horizontally  microprogrammed  with  78-bit  instructions 
decoded  into  37  different  fields.  (As  of  this  writing,  the  machine!  has  been  redesigned  to 
have  a  shorter  microinstruction.  We  hove  not  taken  these  changes  into  account  in  the 
present  work,  but  will  focus  on  the  now  design  in  tho  next  effort.)  Documentation  of  the 
f  TbC  is  givon  in  [Raytheon  Corp  70]. 

One  of  the  criteria  in  the  selection  of  the  FTSC  is  that  it  is  a  real  machine  developed 
outside  our  control.  Wo  believe  that  it  is  possiblo  to  verify  code  for  nearly  arbitrary 
machines,  irrespective  of  the  techniques  used  to  develop  the  code.  This  view  differs 
somewhat  from  those  of  othor  verification  researchers,  notably  [London  77].  To  be  fair, 
it  is  quite  clear  that  much  of  the  labor  in  the  verification  task  can  be  reduced  If 
verification  and.  code  development  are  carried  out  together  and  if  the  strategies, 
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practices,  and  tools  used  to  develop  the  code  are  also  geared  toward  verification.  But 
wo  view  this  os  a  secondary  concern  and  not  fundamental  to  the  verification  task. 
Qulow,  wo  will  mention  where  the  savings  in  labor  would  occur. 

Wo  viow  a  microprogram  verification  system  in  the  following  terms.  A  user  prepares 
formal  descriptions  of  the  host  machine  and  the  target  instruction  set.  He  also  obtains 
a  copy  of  the  microcode  that  runs  on  tho  host  machine  and  allegedly  implements  the 
target  instruction  sot.  He  then  preparos  a  proof  that  the  microcode  does  indeed  behave 
as  desired,  and  submits  all  four  of  these  files-host  description,  microcode,  target 
description,  proof— to  the  verification  system,  which  then  examines  the  target 
description  to  determine  all  aspects  of  its  behavior  needing  implementation.  For  each 
sequence  of  events  that  must  be  implemented,  the  system  symbolically  executes  the 
microcode  according  to  the  rules  of  the  host  machine  and  demonstrates  that  the  required 
sequence  of  uvunts  does  taka  placa. 

No  system  can  ho  nuito  smart  enough  lo  carry  out  oil  possible  demonstrations  completely 
aulom.ilically,  so  somu  holp  may  bo  noudod.  Some  systems  operate  on  the  principle  that 
the  system  should  try  very  hard  to  succeed  on  Its  own  and  then  ask  for  help  after  it  has 
tried  nil  possible  heuristics.  While  this  approach  seems  attractive,  it  has  a  fundamental 
drawback.  When  tho  system  asks  the  user  for  help,  the  user  is  generally  unaware  of 
what  tho  system  already  has  tried  to  do,  what  level  of  detail  is  needed,  or  even  what 
problem  the  system  is  working  on.  The  underlying  difficulty  Is  that  the  user  must  have 
some  idea  of  how  the  system  is  constructed  and  understand  how  to  drive  the  system.  At 
tho  same  time,  wo  note  that  the  system  is  really  trying  to  formally  document  the 
rationale  for  each  instruction  in  the  microprogram.  However,  this  is  just  what  the 
programmer  had  to  do  himself  when  he  wrote  the  program.  Combining  these  two 
observations,  wo  have  taken  the  view  that  the  verification  system  should  be  driven  by 
the  user,  not  the  other  way  around.  The  user  should  have  a  complete  understanding  of 

i 

wluit  liiu  verification  system  will  and  will  not  do,  and  the  user  should  drive  the 
verification  system  toward  bolieving  the  correctness  of  the  code.  In  this  view, 
interaction  botwoon  tho  systom  and  the  user  takes  the  form  of  a  prepared  proof,  and  It 
bocomas  meaningful  to  ask  what  is  the  proper  language  for  writing  proofs.  Wegbrelt's 
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paper  [Wcgbroit  77]  oxploros  this  area  ologontly  for  well-structured  algorithmic 
languages.  l:or  microcodo  generated  with  minimal  assembly  language  tools,  different 
engineering  is  required,  but  the  basic  idea  is  the  some.  At  the  present  time,  our  "proof 
language"  is  nothing  more  than  a  set  of  commands  to  the  proofchecker.  However,  as  we 
gain  experience  with  the  system,  it  becomes  clear  how  to  structure  these  commands  into 
phrases;  thus  tho  development  of  a  proof  language  begins.  At  the  same  time,  it  is 
worthwhile  to  ask  whether  the  production  of  both  the  microcode  and  the  proof  of  its 
correctness  can  share  any  tools.  The  answer  must  be  "yes,"  but  we  have  not  yet 
considered  any  specific  implementation. 

Although  wo  wish  our  system  to  be  as  general  and  as  useful  as  possible,  our  present 
design  horizons  embody  the  following  limitations: 

-  Tiie  purpose  of  the  microcode  must  be  to  implement  the  instruction  set  of  a 
computer.  This  restriction  is  intended  to  limit  the  difficulty  of  specifying 
the  intended  behavior  of  the  microcode.  With  this  restriction,  we  rule  out 
microcode  that  is  just  arbitrary  lower  level  code  to  implement,  say, 
operating  systems,  signal  processing  algorithms,  device  controllers,  etc. 

This  restriction  is  not  really  fundamental  to  our  work  and,  as  we  shall  see, 
does  not  guite  guarantee  that  we  shall  always  have  a  straightforward  way 
to  specify  the  intended  behavior  of  the  machine. 

-  Since  wo  do  not  yet  have  sufficient  tools  to  represent  or  reason  about 
concurrency  or  time-dependent  behavior,  we  demand  that  our  microcode  be 
written  for  a  sequential  machine  and  that  it  Implement  the  instruction  set  of 
a  sequential  machine. 

-  We  intend  that  tho  result  of  this  research  be  a  demonstrable  system  with 
the  real  possibility  that  someone  other  than  ourselves  should  be  able  to 
formula  to  a  task  and  carry  it  out.  Wo  do  not  intend,  however,  that  the 
system  ho  officiant,  completely  robust,  smoothly  human-engineered,  or 
thoroughly  documontod.  Users  of  llic  system  should  understand  the  state 
of  development.  Their  success  rote  will  be  higher  if  they  communicate  with 
us  before  and  during  any  experimentation. 

In  addition  to  the  caveats  above,  the  system  wo  are  building  is  not  yet  ready  for 
rcloaso. 

Carrying  out  a  complete  proof  may  be  fairly  tedious.  Preparation  of  the  formal 
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descriptions  often  appears  to  be  a  streighforward  task  of  encoding  the  information  in  the 
manuals  that  accompany  the  machine,  but  we  have  noticed  that  many  important  details 
are  often  omitted  from  such  documents,  and  others  are  misdocumented.  Programmers 
developing  the  microcode  come  to  understand  these  details  and  use  their  knowledge  to 
write  or  debug  their  code.  If  the  person  writing  the  formal  description  is  not  similarly 
stooped  in  tho  culture  of  the  machine  under  consideration,  a  similar  learning  period  will 
bo  required. 

Writing  tho  proof  may  bo  tedious,  for  three  reasons.  First,  a  complete  understanding  of 
tho  code  is  necessary.  The  programmer  understands  the  code;  the  person  responsible 
for  verification  may  not.  A  period  of  study  may  bo  necessary  before  any  of  the  proof 
can  bo  writlou.  Of  course,  if  the  programmer  were  also  responsible  for  preparation  of 
tho  proof,  then  tho  verification  would  proceed  ail  the  faster.  Unfortunately,  with 
verification  still  in  tho  research  phase,  programmers  who  build  "real"  programs  are  far 
too  busy  to  spend  tiio  extra  timo  required  for  verification.  Also,  since  verification 
requires  some  special  knowledge,  production  programmers  may  not  be  skilled  in  the  art  of 
preparing  formal  descriptions  and  proofs. 

The  second  difficulty  is  that  tho  codo  may  be  relatively  complicated  to  verify.  At  the 
beginning  wo  insisted  that  it  should  he  possible  to  verify  codo  even  If  it  were  written 
without  knowledge  that  it  would  be  subjected  to  verification.  (We're  assuming,  of 
course,  that  tho  codo  does  indeed  work!)  However,  it  is  equally  clear  that  there  are 
many  strategics  for  writing  code  and  that  some  of  them  may  be  equally  good  from  the 
programmer's  point  of  view  but  require  vory  different  levels  of  effort  in  verification. 

Tho  third  difficulty  is  that  proofs  may  be  tediously  long.  We  have  said  that  the  user 
must  drive  tho  verification  system  with  a  proof  and  that  the  verification  system  must 
procood  so  as  to  yiva  the  user  a  clear  idea  of  what  the  system  is  doing.  However,  a 
trivial  way  to  build  such  a  system  is  to  make  it  extremely  simple,  with  the  result  that 
proofs  will  ho  oxtromoly  long  and  require  the  user  to  spend  a  long  time  preparing  them. 
In  tho  extreme,  this  is  not  permissible;  it  Is  necessary  to  build  the  system  with  enough 
knowledge  so  the  "straightforward"  deductions  are  carried  out  automatically.  There  is 
no  possibility  that  any  system  can  knew  a  "maximum"  of  knowledge,  for  there  will  always 


bo  problem:;  that  can  bo  proven  with  a  system,  but  not  proven  automatically.  At  the 
snmo  time,  tlusro  is  no  limit  to  making  a  system  smarter;  we  can  always  go  beyond  the 
previous  limits  and  build  a  next  system  that  understands  more  than  the  last.  Clear 
measures  of  the  smartness  of  one  system  compared  to  another  do  not  yet  exist,  but  It  Is 
a  question  that  is  iikely  to  gain  attention  as  various  verification  systems  are  used  for 
larger  and  larger  problems. 

As  we  said  earlier,  we  have  restricted  our  interest  to  microcode  that  implements  the 
instruction  set  of  some  computer.  The  intention  of  this  limitation  is  to  make  it  easy  to 
specify  the  intended  behavior.  Unfortunately,  this  restriction  does  not  quite  work.  In  the 
description  of  the  host  architecture,  we  have  no  difficulty  in  formalizing  all  aspects  of 
concern,  excepting,  of  course,  timing  anti  concurrency.  We  view  the  host  machine  as 
operating  on  bitstrings  of  finite  length.  The  operators  for  bitstrings  are  concatenation 
and  selection,  logical  operations,  e.g.,  AND.  OR  and  NOT,  and  the  simple  integer  arithmetic 
operations.  At  the  target  level,  however,  we  have  not  been  so  fortunate.  Bitstrings 
riM.iin  t he  dominant  datatype,  and  all  of  the  bitstring  operators  are  still  required,  but 
new  operations  exist  that  are  not  simply  characterized  by  short  descriptions.  Floating 
point  nrithmot.c  is  the  most  obvious  and  extensive  area,  but  some  machines  have  other 
instructions  whose  behavior  is  quite  difficult  to  characterize  in  lerms  of  bitstrings.  Edit 
and  format  instructions  provide  many  examples,  as  do  instructions  that  find  the 
iowost-ordor  or  higher-order  1  bit. 

Tin:  FTSC  computer  is  blessed  with  the  usual  complement  of  floating  point  instructions; 
indeed,  it  even  has  a  floating  point  square  root  instruction.  On  the  grounds  that  avoiding 
these  instructions  would  trivialize  the  effort  and  leave  us  an  undetermined  distance  from 
realizing  a  system  capable  of  verifying  real  microprograms  for  real  machines,  we  decided 
to  tackle  tire  floating  point  arithmetic  heat  on. 

We  divided  the  specification  of  the  target  machine  Into  two  levels.  The  first  is  written  in 
tiie  same  terms  as  the  host  machine  description.  It  is  restricted  to  simple  bitstring 
operators.  At  this  level,  the  simple  target,  machine  instructions,  e.g.,  load,  store,  Integer 
add,  jump,  etc.,  uro  stated  os  succinctly  as  they  will  ever  be  stated  and  no  further  work 
is  required.  Tho  floating  point  instructions,  however,  look  like  short  but  complicated 


algorithms  that  provide  an  explicit  view  of  how  the  words  are  divided  into  a  mantissa  and 
exponent,  how  normalization  takes  place,  etc. 

for  those  instructions,  we  provide  a  higher  level  of  specification  that  shows  that  the 
result  of  that  algorithmic  specification  has  certain  properties.  This  higher  level  of 
specification  requires  the  introduction  of  the  reals,  and  the  properties  are  stated  in 
terms  of  the  interpretation  of  the  floating  point  bitstrings  as  real  numbers.  For  example, 
the  desired  property  of  the  square  root  instruction  is  that  it  computes  the  largest 
floating j>oi»t  number  whose  square  is  not  larger  than  the  original  number.  (The  notion  of 
"largest  floating  point  number"  roquiros  oven  a  little  more;  the  granularity  of  the  floating 
point  numbers  is  also  an  issuo.) 

In  the  work  to  date,  wo  have  written  a  complete  specification  of  the  FTSC  at  both  the 
host  and  algorithmic  target  level,  but  wo  have  not  defined  the  properties  required  of  the 
floating  point  instructions  except  for  the  square  root  instruction.  We  have  focused  on 
the  square  root  instruction  simply  because  it  seemed  to  expose  all  of  the  issues  likely  to 
come  up  in  any  other  instruction. 

Die  basic  plan  for  verifying  tlio  correctness  of  tho  microcode  thus  has  two  parts.  One 
part  is  to  verify  that  tho  microcode  running  on  tho  host  machine  implements  the 
algorithmic  target  level.  The  second  part  is  to  verify  that  the  algorithmic  target  level 
lias  tho  additional  properties  desired. 

At  the  present  time,  wo  have  completed  the  proof  that  the  algorithmic  target  description 
of  tie*  square  root  instruction  has  the  desired  property.  We  have  not  yet  proven  similar 
properties  for  othor  instructions,  nor  have  we  proven  the  correspondence  between  the 
fiost  machine  and  the  target  instruction  set,  for  the  FTSC.  We  have,  however,  created  a 
"ole,  fictitious  machine  and  carried  out  a  complete  proof  of  the  correctness  of  its 
microcode.  This  small  machine  is  called  tho  TOY  machine.  Both  of  these  proofs  are 
documented  in  chapter  four. 

Completion  of  proofs  is  one  measure  of  progress,  but  there  is  much  that  precedes  the 
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ability  to  carry  out  proofs.  A  sound  theoretical  basis  must  exist  or  be  developed  and  a 
functioning  proof  system  must  be  developed.  These  activities  have  consumed  the 


majority  of  our  timu  aiul  resources. 


In  chapter  two,  wo  discuss  the  thooretical  basis  for  our  proof  system  and  introduce  the 
ionriuarjn  wo  uso  for  expressing  the  behavior  of  machines  and  the  properties  of 
programs,  in  chapter  three,  we  outline  the  structure  of  the  proof  system  and  give 
details  for  selected  components. 

Hus  work  is  still  in  progress.  The  details  of  language,  structure  and  capabilities  are  all 
evolving. 


2.  LANGUAGE  AND  THEORY 


In  this  chapter  wo  discuss  the  formal  basis  of  and  the  language  we  have  chosen  for  both 
encoding  our  descriptions  of  machines  and  reasoning  about  the  course  of  computations. 
Internally,  our  notation  is  chosen  for  its  precision  and  ease  of  processing,  qualities  that 
contrast  with  the  desire  for  compactness  and  richness  in  the  languages  read  and  written 
by  humans.  Both  levels  exist,  and  there  must  be  translation  between  them.  As  often 
happens,  subtle  and  important  issues  emerge  in  the  translation.  At  IBM,  the  difficulties  of 
using  two  levels  of  language  hove  been  avoided  by  designing  a  special-purpose 
language  that  is  both  computationally  tractable  and  not  too  unwieldy  for  humans.  That 
language  is  documented  in  [Joyner  et  al.  78]. 

2.1  ISPS 

To  represent  tiro  host  and  targot  machines,  we  have  chosen  to  use  the  ISPS  language. 
ISPS,  a  derivative  of  Boll  and  Nowell's  ISP  language  [Bell  and  Newell  71],  Is  now  in 
modest  use  by  a  number  of  organizations.  Documentation  of  the  current  version  is  given 
in  [llarbacci  et  al.  77];  the  examples  in  chapter  four  are  written  In  ISPS. 

Descriptions  of  machines  have  boon  written  in  ISPS  for  a  number  of  different  purposes, 
including  simulation,  architecture  evaluation,  documentation,  computer-aided  design,  and 
(in  variants  of  ISPS)  automatic  genorution  of  code  generators  and  assemblers.  This 
variety  of  activity  associated  with  the  language  is  useful  In  two  ways.  On  the  one  hand, 
thu  use  by  largo  numbors  of  people  improves  tho  possibility  that  a  standard  will  emerge, 
that  documentation  of  computers  will  be  more  accurate  and  more  complete,  and  that  the 
task  of  preparing  formal  descriptions  of  tho  host  and  target  levels  of  a  microprogrammed 
machine  will  bo  carriod  out  by  tho  machine  designers  Instead  of  by  the  verification  group. 

On  the  otlior  hand,  tho  wide  variety  of  applications  using  ISPS,  each  with  Its  own 
software  to  process  ISPS  descriptions,  has  tended  to  expose  the  lack  of  a  precise 
semantics  for  tho  language.  As  an  oxpoiiment  to  gain  some  leverage  on  the  semantics 
of  ISPS,  Pcto  Alfvin  developed  a  denotational  semantic  definition  of  AMDL,  an  abstract 
syntax  version  of  ISPS  in  use  at  ISI  [Alfvir.  79], 


As  wo  montioncd  in  tho  overview,  while  it  may  look  simple  to  encode  the  details  of  a 

machine's  instruction  sot  in  ISPS,  it  muy  bn  tedious  In  actuality.  In  the  case  of  the  FTSC, 

a  machine  under  dovalopment  and  redesign,  a  number  of  small  but  important  details  were 
either  undocumented  or  misdocumentod.  We  developed  simulation  tools  to  execute  the 
descriptions  wu  wrolo  and  used  the  simulations  to  execute  the  diagnostics  for  the 
machine  at  both  tho  host  and  targot  levels.  In  essence,  this  amounted  to  a  "verification 
by  testing"  approach;  sinco  tho  microcode  itself  was  used  In  some  of  these  tests,  it  is 
reasonable  to  ask  if  wo  porturbod  tho  description  of  the  machine  in  order  to  make  the 

code  work.  Stated  another  way,  how  do  we  know  that  the  description  of  the  host 

machine  is  an  accurate  representation  of  how  the  hardware  really  works,  and  how  do  we 
know  that  tho  description  of  the  target  tnuchine  is  an  accurate  representation  of  how 
tho  target  machine  is  supposed  to  work?  There  can  be  no  completely  satisfactory 
answers  to  those  questions.  The  descriptions  at  both  levels  must  be  accepted;  they 
cannot  bo  chocked  in  any  rigorous  sense  within  the  confines  of  the  microcode 
verification  paradigm.  If  there  exists  another  description  at  a  higher  or  lower  level,  then 
tho  corresponding  descriptions  may  bo  checked  against  it.  However,  this  merely  pushes 
thu  problem  off  one  level,  and  there  is  no  ultimate  exemption  from  a  requirement  to 
accept  tho  bottom  lovol  description  as  the  way  the  machine  actually  works  and  the  top 
lovol  description  as  tho  way  the  system  is  supposed  to  work. 

Comploto  assurance  having  been  denied  us,  we  can  ask  what  lesser  assurance  is 
available.  By  using  a  language  understood  by  a  number  of  people  (In  particular  by  the 
designers  of  tho  machine,  the  microprogrammers  of  the  machine,  and  the  programmers  at 
thn  assembly  language  level)  we  can  have  some  hope  that  they  all  share  the  same 
understanding  of  the  machine  if  they  were  to  depend  upon  the  same  descriptions  as 
thoir  reference.  This  is  not  yet  tho  case  for  any  machine  with  any  description  system, 
but  wo  see  no  reason  why  it  coulo  not  be.  In  the  course  of  writing  the  formal 
descriptions,  tho  "outsider"  may  find  himself  In  a  question  and  answer  dialogue  with  the 
machine  designers,  in  ordor  to  clarify  the  informal  descriptions.  See  the  appendices  for 
an  oxamplo  of  our  dialogue  with  the  designers  of  the  FTSC. 

To  compluto  our  discussion  of  ISPS,  we  again  montlon  that  ISPS  does  not  provide 
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primitives  for  representing  floating  point  operations:  we  have  had  to  code  them  in  ISPS 
as  small  algorithms.  Since  the  lack  of  standard  notions  and  designs  of  floating  point 
arithmetic  is  a  common  problem,  the  choice  of  another  language  would  not  have  Improved 
matters. 


2.2  STATE  DELTAS 

in  ardor  to  build  a  proof  system,  a  formal  basis  for  reasoning  about  machines  is  required. 
Ordinary  first-order  predicate  calculus  is  often  used  as  a  foundation,  but  it  provides  no 
machinery  for  reasoning  about  time  or  situations  that  change  with  time. 


There  .no  many  possible  solutions.  Ours  has  been  the  development  of  an  extension  to 
the  first-order  predicate  calculus  by  the  addition  of  sentences  called  state  deltas. 
State  deltas  wero  first  introduced  in  [Crocker  77].  For  a  more  formal  treatment  see 
[Marcus  70],  To  motivate  tho  development  of  state  deltas,  we  give  the  observations 
ami  decisions  that  support  our  formulation. 

-  It  is  simple  to  think  in  theoretical  terms  that  a  computer  can  be 
characterized  by  a  transition  function  that  maps  state  vectors  into  state 
vectors.  Given  an  initial  state  vector  and  a  statement  of  the  transition 
function,  ordinary  mathematical  tools  will  provide  tho  machinery  for 
reasoning  about  successive  states  of  the  machine.  However,  direct  use  of 
this  approach  becomes  unwieldy  for  even  the  simplest  example. 

-  One  of  tho  first  difficulties  is  tho  description  of  the  state  vector.  It  Is 
guile  inconvenient  to  think  of  tho  state  vector  as  a  single  domain.  For  all 
real  machines,  tho  state  voctor  is  a  messy  patchwork  of  various  domains. 

Fuch  of  tho  storage  locations  in  tho  machine  is  a  piece  of  the  state  vector. 

Tho  primary  memory  is  perhaps  the  most  regular  component,  but  there  aro 
many  other  components.  Also,  it  moy  bo  daslrablo  to  subdivide  the  memory 
into  smaller  piocos.  To  deal  with  this,  we  use  the  usual  programming 
practice  of  assigning  names  to  diflorent  places.  A  place  is  essentially  a 
component  of  tho  state  vector.  Given  the  list  of  places  that  comprise  the 
state  voctor,  wo  will  not  actually  need  to  symbolize  the  state  vector  as  a 
single  object.  Wo  will  not  oven  need  to  know  exactly  how  the  components 
comprise  tho  state  vector,  e,g.,  it  is  not  necessary  to  know  if  the  state 
voctor  is  represented  as  a  tuple  or  whether  the  program  counter  is,  say, 
tho  first  or  second  element  of  that  tuplfe. 

-  Tho  prociso  granularity  of  timo  Is  not  really  of  interest.  We  do  not  care 


11 


whether  n  particular  computation  takes  one  or  two  time  steps.  Instead,  we 
care  that  certain  states  follow  one  another  eventually.  Accordingly,  we 
avoid  describing  individual  transitions  and  describe  the  effect  of  multiple 
transitions  instead.  The  result  is  quite  similar  to  Manna  and  Waldinger's 
intermittent  assertion  idea  [Manna  &  Waldinger  73],  which  is  derived  from 
Burstali's  paper  [Burstall  74].  Wc  make  use  of  a  precondition  and  a 
postcondition,  and  our  state  delta  encodes  the  idea  that 

if  the  precondition  holds  at  some  point  in  time, 

then  thuro  will  bo  a  lator  time  at  which  the  postcondition  holds. 

While  it  might  bo  possible  to  statu  tho  behavior  of  a  machine  in  a  single 
noiilence,  it  would  ho  quite  unwieldy.  Wo  make  use  of  a  collection  of  state 
deltas  to  specify  tho  behavior  of  a  machine.  Each  state  delta  defines  the 
behavior  of  thu  machine  in  only  particular  circumstances.  Of  course,  It  is 
not  necessary  to  cover  all  possible  circumstances;  It  Is  perfoctly 
reasonable  to  leave  tho  behavior  of  the  machine  undefined  in  some  cases. 

Most  of  tho  components  of  the  state  vector  are  unchanged  at  each  step. 
Any  straightforward  description  of  the  transition  function  would  be 
dominated  by  simple  statements  of  equality  between  large  sections  of  the 
old  and  new  states.  To  reduce  this  burden,  our  formalism  encodes  the 
assumption  that  all  of  the  state  remains  unchanged  except  tor  a  list  of 
places  in  the  state  vector  explicitly  named.  Accordingly,  a  state  delta  has 
a  modification  list.  The  semantics  of  a  state  delta  includes 

if  the  precondition  holds  at  some  point  in  time, 

then  thera  will  come  a  time  ot  which  the  new  state  is  the  same 
nr.  tho  present  stoto  except  possibly  for  the  values  in  the 
places  listed  in  thu  modification  list,  and 

at  that  time  the  postcondition  will  also  hold. 

Even  with  the  implicit  assumption  that  most  of  the  state  remains  unchanged 
from  one  state  to  another,  it  may  lie  necessary  to  include  many  details  In 
tho  precondition.  Quite  often  the  precondition  includes  the  requirement 
that  much  of  tho  present  stoto  s  identical  to  a  particular  prior  state.  This 
introduces  a  third  time  into  tho  formalism.  We  have  encoded  this  condition 
with  another  list  of  places,  called  the  environment  list.  The  semantics  of 
statu  delta  are  now  statod  as 

if  tho  contents  of  tho  plucos  lltttod  In  tho  environment  list  are 
tho  some  at  somo  time  as  they  were  at  an  earlier  time  t q,  end 
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if  the  precondition  is  true  ot  time  t^, 

thun  there  will  be  a  later  time  t2  in  which  the  new  state  is  the 
same  as  the  state  at  time  everywhere  except  possibly  at  the 
places  listed  in  the  modification  list,  and 

the  postcondition  will  also  hold. 

-  To  simplify  our  bookkeeping  about  times  and  states,  we  organize  all  of  our 
thoughts  in  terms  of  a  current  time.  In  the  formulation  above,  we  anchor  tg 
to  the  current  time.  We  can  restate  the  formulation  as 

if  at  some  future  time  t^  all  of  the  values  in  the  places  listed  in 
the  environment  list  arc  the  same  as  they  are  now,  and 

if  the  precondition  holds  at  that  time, 

then  there  will  come  a  time  t^  whose  values  are  the  same  as  at 
time  t^  everywhere  except  possibly  in  the  places  list  in  the 
modification  list,  and 

the  postcondition  will  hold. 

-  While  this  formulation  is  quite  close  to  what  we  need  to  support  efficient 
reasoning  about  places  and  states,  the  requirements  imposed  by  the 
modification  and  environment  lists  are  more  difficult  than  they  look.  As 
stated,  it  is  permitted  that  the  values  inside  the  environment  list  and 
outside  tho  modification  may  change  in  the  interim,  as  long  as  they  are 
restored  at  tho  end  of  the  interval.  We  have  found  it  more  useful  to 
tighten  this  requirement  so  that  the  values  tbot  must  bo  the  same  at  the 
ends  of  the  time  intervals  are  in  fact  never  changed  during  the  Intervals. 
It  funis  out  that  tightening  the  restriction  of  the  environment  and 
modification  lists  does  not  remove  any  essential  power.  On  the  contrary, 
this  new  version  allows  tho  rostrlctod  uso  of  tho  modal  operator  "during"  to 
form  sentences  which  aro  not  expressible  using  only  pre-  and 
post comidions.  Our  formulation  is  now 

if  the  values  listed  in  the  environment  list  remain  unchanged  from 
now  until  some  future  time,  and 

if  tho  precondition  also  holds  at  that  time, 

thon  ot  tho  end  of  some  succeeding  jtime  interval  during  which  at 
most  only  the  values  listed  in  the  modification  list  will  have 
changed,  and 
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the  postcondition  will  hold. 


Nolo  that  thnro  is  no  requirement  that  values  that  are  unchanged  from  now 
until  the  precondition  becomes  true  remain  unchanged  when  the 
postcondition  becomes  true.  In  other  words,  it  is  possible  that  the  same 
place  may  be  listed  in  both  the  environment  and  modification  lists.  Later, 
wo  will  see  (ho  use  and  effect  of  such  an  intersection. 


Thu  syntactical  form  of  a  state  delta  is 

(GO  (pres  P) 

(mod:  M) 

(env:  E) 

(poet:  Q) ) 

whore  P  and  G  arc  usually  first  ordor  so  ltoncos  In  some  language,  but  may  In  fact  be 
state  deltas  tlmmsoivos,  and  M  is  a  list  of  places,  as  Is  E.  See  Chapter  4  for  additional 
examples  of  state  deltas. 


Note  that  thu  logical  implication  P  implies  G  (in  a  given  state)  is  equivalent  to  the  state 
delta 


(Go  (pres  P) 

(mod:  ) 

(env:  0HEGA) 

(post:  Q ) ) 

being  true  in  that  state,  where  OMEGA  is  a  list  of  all  places,  or  equivalently  a  single 
state  "containing"  all  others. 


Also  note  that  one  state  delta  may  be  derived  from  two  others  by  a  kind  of  case 
analysis. 


(GO  (pre:  P  AND  ?') 

(mod:  N) 

(env:  E) 

(post:  0)) 

and 

(50  (pre:  P  AND  (NOT  f')) 

(mod:  Hi 
(env:  E) 

(post:  Q)) 
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hold  in  a  certain  state,  than 

(SO  (pre:  P) 

(mod:  M) 
lunv:  E) 

(post:  Q)) 

holds  in  that  stale. 

An  important  tool  is  the  “dot"  operator  ,R,  which  when  applied  to  a  place  R  (for 
“Register")  represents  the  value  or  contents  of  that  place.  Thus  a  state  change  entails 
a  redefinition  of  dot,  not  a  reinterpretation  of  the  place  itself. 

When  dot  is  used  in  a  state  delta  it  always  refers  to  the  contents  at  the  time  of  the 
precondition.  In  order  to  reference  the  contents  of  a  place  at  the  time  of  the 
postcondition,  the  symbol  #  is  used.  For  example, 

(SD  (pre:  ,R  GTR  8) 

(mod:  R) 

(rnv:  ) 

(post:  0R-.R-1)) 

moans  that  d  (ho  valua  of  R  is  greater  than  0,  then  at  some  later  time  the  new  value  will 
be  one  loss  (and  nothing  changed  along  the  way  except  for  R). 

Hero  is  an  example  of  deriving  one  state  delta  from  another  by  a  form  of  induction: 
Assume  tiro  contents  of  places  are  nonnegative  integers.  If 

(SD  (pre:  P(.R)  AND  JR  GTR  B) 

(mod:  M) 

(env:  E) 

(poot:  P (UR)  AND  ,R  GTR  #R)) 

holds  in  a  certain  stain,  and  in  addition  if  M  and  E  represent  disjoint  sets  of  places,  then 

(pro:  PUR)  AND  JR  GTR  B> 

(mod:  M) 

(onv:  E) 

(post:  P(Oi) 

holds  in  that  state. 

It  is  obvious  how  ait  input-output  specification  can  be  stated  using  state  deltas.  In  the 
next  sections  wo  shall  oxplaln  how  a  simulation  relation  between  two  programs  can  be 
proved  using  state  doitas. 
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l  or  now  lot  us  point  out  how  a  set  of  state  deltas  con  be  viewed  as  a  program.  Assume 
th.it  wo  arc  given  a  set  of  state  deltas,  ordered  in  some  way,  and  an  "initial"  state.  The 
first  state  delta  (according  to  the  above  ordering)  whose  precondition  is  true  in  the 
current  state  may  ho  "applied",  thus  transforming  the  state  into  that  specified  by  the 
postcondition  (and  the  modification  list).  Actually  the  term  "state"  should  perhaps  be 
replaced  by  "set  of  states"  sinco  wo  do  not  demand  that  the  postcondition  completely 
determine  the  state;  for  example,  the  actual  values  of  some  places  may  not  be 
determined,  but  rather  some  properties  of  these  values  are  known.  The  components 
(sentences)  ol  the  old  state  which  were  dependent  on,  or  "supported  by",  places  In  the 
modification  list  are  removed  from  the  state,  and  the  list  of  sentences  In  the 
postcondition  are  added  to  tho  remaining  sentences. 

Now  tin*  process  is  rupeatod  in  tlio  now  state.  This  process  is  called  symbolic 
execution. 

It  is  also  possible  to  view  a  somewhat  arbitrary  program  as  a  set  of  state  deltas,  or  to 
translate  a  program  into  state  deltas,  as  is  discussed  in  Section  2.4. 


2.3  SIMULATION 

As  stated  in  tho  overview,  tho  process  of  microcode  verification  can  be  divided  Into  two 
parts:  the*  first  showing  that  the  Host  Machine  implements  the  Target  Machine,  the 
second  showing  that  tho  Target  Machine  satisfies  the  Top  Level  Specification.  We  shall 
now  discuss  tho  first  of  these  parts. 

Lot  us  think  on  tlio  lovol  of  abstraction  where  both  the  host  and  microcode  and  the 
target  may  be  considered  as  programs  A{,  A^  Intuitively,  Aj  simulates  A?  if  Al  can  "do" 

anything  A,  can;  that  is,  the  state  changes  due  to  are  reflected  in  the  state  changes 

that  Aj  causes.  The  state  changos  for  Aa  and  separately  are  computed  using  the 

symbolic  execution  of  tho  provious  section.  To  prove  that  Ai  (symbolically)  simulates  A2 

we  need  to  establish  a  correspondence  totween  the  states  ol  Aj  and  those  of  A2  such 

that  given  two  corresponding  states,  S2  (for  A?)  and  Sl  (for  A  ),  if  S2'  is  the  next  state 

after  S,  arrived  at  by  executing  AJ(  then  the  (a)  state  corresponding  to  S2'  can  be 

arrived  at  by  nxocuting  Ax  from  (though  need  not  be  the  very  next  state  after  St). 


16 


In  tho  system  implementation,  a  state  is  specified  (as  In  the  precondition  or  postcondition 
of  a  .state  delta)  by  a  list  of  first  order  sentences  and  SDs,  and  the  correspondence 
between  states  is  specified  by  a  function  culled  MAPPING.  Again,  recall  that  "state"  as 
used  here  is  not  necessarily  a  complete  description.  Thus  MAPPING  is  actually  a 
correspondence  between  sets  of  complete  states. 

2.4  TRANSLATION  OF  ISPS  INTO  SDS 

l.sl\S  is  a  relatively  well  known  language  suitable  for  machine  descriptions.  We  will  see 
that  SD  notation  is  suitable  for  representing  intermediate  proof  steps,  performing 
symbolic  execution,  and  utilizing  the  efficiency  of  the  modification  list,  in  order  to  retain 
the  advantage  of  ISPS  us  an  input  language  and  SDs  as  an  internal  notation,  we  need  to 
translate  ISPS  descriptions  into  SDs. 

If  wo  invent  a  place  to  represent  the  internal  control  state  of  a  machine  and  we  a^ign  a 
symbolic  value  to  the  control  place  for  each  statement  in  an  ISPS  program,  the 

program  could  be  represented  with  a  set  of  SDs,  where  each  SD  represents  a  possible 
state  change.  References  to  control  states  could  be  made  by  including  predicates  of 
the  form  .PC=labol  in  the  precondition  ond  postcondition  (PC  represents  the  internal 
control  state  "program  counter";  "label"  represents  the  control  value).  Representing  all 
the  state  changes  with  SDs  has  two  drawbacks:  the  thread  of  control  that  is  Implicit  in 
the  ISPS  representation  is  lost  and  is  encoded  explicitly  into  the  precondition  and 
postcondition;  the  SD  notation  is  different  from  the  familiar  ISPS  (and  somewhat  more 
complicated). 

Nested  State  Deltas 

Tin*  scheme  we  are  using  is  motivated  by  the  need  to  model  the  control  mechanism  inside 
a  machine.  In  an  oarlier  formulation,  we  modelled  the  control  mechanism  as  a  single 
variable  that  look  on  explicit  valuos.  Each  procondition  and  postcondition  mentioned  the 
Vitim;,  n.g.,  .MicroPC=A312,  ond  this  control  place  was  also  mentioned  in  the  modification 
list  of  every  SI).  It  did  not,  of  course,  occur  In  tho  environment  list.  Since  the  names  of 
the  control  state  valuos  were  completely  artificial  and  the  explicit  appearance  In  the 
pro-  and  postconditions  of  these  equations  was  very  cumbersome,  we  revised  the 


formulation  to  an  entirely  equivalent  scheme  that  simply  made  implicit  use  of  the  value  of 
control  place.  The  only  property  of  the  control  place  we  cared  about  is  that  it  made 
some  precondition  truo.  By  embedding  the  next  SD  in  the  postcondition  of  the  current 
SO.  the  next  SD  is  automatically  made  valid  when  the  current  SD  is  applied 
("executed").  Of  course,  its  validity  disappears  when  the  control  place  is  changed,  so  it 
i:;  necessary  that  the  name  of  the  control  place  appear  in  the  environment  list  of  the 
now  SD.  This  is  what  gives  rise  to  tho  appearance  of  the  same  control  place  in  both  the 
environment  and  modification  lists.  Of  course,  there  are  some  SDs  that  will  not  have  the 
control  place  in  the  environment  list.  Tho  tops  of  loops  need  to  be  around  forever,  and 
we  must  resort  to  using  names  for  the  values  of  the  control  place  at  those  points.  SDs 
that  exit  from  blocks  will  not  generally  have  SDs  in  their  postconditions;  Instead  they  will 
•  ?t  relevant  values  of  tho  control  place. 

Instead  of  describing  a  program  by  a  sot  of  SDs  (one  for  each  possible  state  change)  we 
could  describe  it  with  ono  SD  that  represents  the  first  state  change  and  has  a  nested 
SD  that  represents  the  rest  of  the  program  in  its  postcondition.  During  symbolic 
execution,  the  process  of  applying  an  SD  is  repeated.  The  following  happens  for  each  SD 
application:  tho  appropriate  state  change  is  mode;  the  nested  SD  that  represents  the 
rest  of  the  program  is  added  to  the  current  state;  and  the  SD  just  applied  is  removed 
from  tho  current  state  if  it  is  supported  by  the  (modified)  control  place. 

Tho  TR  Notation 

1  ho  use  of  tlm  TR  notation  Is  a  further  compression  of  the  translation  from  JSPS  to  SDs. 
Wo  noticed  that  it  was  unnecessary  to  translate  an  ISPS  description  entirely  into  SDs 
and  then  wotk  with  the  SDs.  Instead,  we  embedded  the  translation  process  In  the 
operation  of  tho  proof  system  and  carried  out  just  one  step  of  the  translation  at  a  time. 
In  us.'ioncc,  wo  now  encode  tho  value  of  tho  control  place  as  a  formula  that  tells  what  to 
do  next.  That  formula  is  basically  ISPS  code,  with  embellishments  to  tell  us  where  we 
aro  in  tho  code  and  to  keep  track  of  the  environment  established  by  ISPS  scope  rules. 

To  improve’  tho  cumbersome  notation  of  nested  SDs  to  represent  the  tail  of  a  program, 
wo  defined  a  function  called  TR  that  maps  an  ISPS  description  into  an  SD  or  a  set  of 
SDs.  Wo  distinguish  between  ISPS  descriptions  whose  first  statement  is  an  assignment 
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statement  <iiid  those  who  start  with  a  control  change  (conditional  or  unconditional).  In 
c«»°  ai*  assignment,  the  TR  maps  an  ISPS  program  into  an  SD  whose  precondition  is 
empty;  thn  modlist  includes  a  control  placo  (MicroPC)  and  the  name  of  the  register  that 
is  being  assigned  to;  tho  onv/list  Includes  only  MicroPC;  the  postcondition  includes  the 
effect  of  the  assignment  and  a  TR  whoso  parameter  Is  the  tall  of  the  ISPS  program.  In 
case  of  a  control  change,  the  TR  maps  an  ISPS  program  into  a  set  of  SDs.  For  each  SD, 
the  precondition  includes  the  condition  that  leads  to  the  control  change,  the  modlist  and 
onvlist  include  MicroPC,  and  the  postcondition  includes  a  TR  with  the  corresponding  rest 
of  tho  ISPS  program.  Tho  symbolic  execution  using  TRs  is  very  similar  to  nested  SDs, 
except  that  tho  rest  of  the  program  is  represented  as  a  TR  applied  to  an  ISPS 
description. 

Marking  ISPS  Programs 

The  set  of  SDs  that  represents  an  ISPS  program  is  not  unique.  We  saw  that  it  ranges 
from  an  SD  tor  oach  ISPS  statement  to  a  single  SD  for  the  whole  program.  It  depends  on 
the  "granularity"  that  tho  ISPS  description  is  Intended  to  be  broken  into.  This  granularity 
is  specified  by  special  markings  of  the  ISPS  description:  Every  SD  that  is  part  of  the 
description  of  a  marked  ISPS  program  must  cover  a  path  of  execution  between  two 
markings. 

A  control  .stain  of  an  ISPS  description  is  a  label  or  a  procedure-entry  (that  specifies  the 
"rest  of  the  program").  A  marking  Is  a  special  kind  of  control  state.  The  minimum  set  of 
markings  needed  to  specify  simulation  are  the  entries  and  exits  of  all  the  procedures. 
Markings  could  bo  added  In  order  to  allow  more  SDs  (i.e.,  a  finer  granularity).  They  should 
be  added  to  break  all  the  loops,  for  simplicity.  Marking  should  also  be  added  In  order  to 
avoid  covering  tho  same  oxocution  path  by  more  than  one  SD,  for  efficiency. 

Tho  Translation  Procoss 

A  marking  M  is  a  "successor"  of  M^  If  M(  belongs  to  the  set  of  markings  that  can  be 
reached  by  symbolic  execution  from  M^  without  visiting  any  other  marking.  The  translation 

algorithm  gonnratos  ono  SD  for  each  path  of  execution  between  two  succeeding 
markings  that  aro  reachable  from  the  Initial  one.  The  number  of  SDs  generated  is 
determined  by  tho  granularity  (i.e.,  the  number  of  markings).  When  showing  simulation,  we 
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will  usually  use  a  very  fine  granularity  for  the  lower  level  machine  (the  Host)  and  a 
coarser  one  for  the  Target.  The  TR  function  is  used  for  performing  the  symbolic 
execution. 

I  or  simplicity  wo  will  refer  in  this  paragraph  to  the  translation  of  the  target  machine.  The 
control  place  for  the  target  machine  is  MacroPC. 

The  following  information  is  accumulated  during  the  symbolic  execution  for  generating 
each  St):  all  the  "path  conditions"  that  have  to  be  true  in  order  to  reach  a  successor; 
the  list  of  places  that  are  modified  during  execution;  the  new  symbolic  state.  The  new 
i>D  covers  the  path  of  execution  between  a  marking  and  its  successor,  and  includes  the 
following:  in  the  procondition  the  accumulated  path  condition  and  .MacroPC»"initlal  label"; 
in  the  modii’.t  tiio  accumulated  modified  places  and  MacroPC;  the  envlist  Is  empty;  In  the 
postcondition  tho  accumulated  symbolic  stato  and  .MacroPC»lnbel.  A  concrete  example 
of  translation  of  an  ISPS  program  is  shown  in  a  subsequent  chapter. 
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2.5  THE  SYSTEM  —  OVERVIEW 

Tlio  system  is  described  in  detail  In  Appendix  A.  Here  we  Just  describe  enough  to  serve 
as  background  for  the  next  chapter.  For  any  additional  information,  see  Appendix  A. 

Tim  MICHOVi  H  system  consists  of  the  following  components:  User  Interface,  ISPS 
Translator  (described  in  the  previous  section),  Kernel,  Data  Base,  Place  System,  and 
Simplifier.  Tlio  User  Interface,  with  the  help  of  the  ISPS  Translator,  converts  the  user's 
input  to  u  sequence  of  basic  proofsteps.  The  Kernel  processes  the  proofsteps  with  the 
help  of  the  Data  Base,  Place  System,  and  Simplifier.  The  Data  Base  keeps  track  of  the 
current  state,  tho  Placo  System  keeps  interdependencies  among  places,  and  the 
Simplifier  simplifies  expressions  in  the  current  state. 

The  Data  Base  contains  facts  which  may  change  as  the  state  changes  through  symbolic 
execution,  say.  Thus  it  contains  facts  relating  to  the  contents  of  places  (these  facts  do 
not  necessarily  uniquely  determine  those  contents,  e.g.,  contents  of  A  greater  than  0),  or 
relating  to  some  arithmetical  variables  like  induction  variables. 

The  Place  System  holds  "permanent"  facts  about  places,  for  example  which  places  are 
subplaces  of  other  places.  This  is  tho  "Covering"  relationship: 

(Covering  A  (CB1  LI)  ...  (Bn  Ln))) 

means  A  is  a  place  with  disjoint  subplaces  B1  of  length  LI,  ....  Bn  of  length  Ln. 

The  MICHOVI; H  system  as  a  whole  can  be  thought  of  as  performing  deductions  involving 
dynamic  statements  (state  deltas).  Tho  Simplifier  is  the  component  performing  static 
deductions.  Titus  the  simplifier  contains  procedures  for  simplifying  expressions  In  a 
given  state.  If  the  expression  is  a  sentence  (e.g.,  predicate),  and  the  simplified  result  is 
T,  then  that  sentence  is  true  in  tho  given  state. 


3.  EXPERIENCE  AND  EXAMPLES 

The  bulk  of  our  work  has  used  examples  taken  from  the  FTSC.  As  we  outlined  In  the 
overview,  we  have  divided  the  FTSC  target  description  Into  two  levels.  One  level 
provides  an  algorithmic  description  for  the  instructions.  For  the  simple  Instructions,  e.g., 
load,  store,  and  Integer  arithmetic  Instructions,  this  level  of  description  Is  easy  to  read 
and  requires  no  further  refinement.  However,  for  the  floating  point  instructions,  an 
algorithmic  description  of  the  effect  of  an  Instruction  Is  nearly  opaque  and  Is  useful  only 
to  a  specialist  who  needs  to  track  down  the  detailed  results  for  particular  cases.  For 
these  Instructions,  we  need  to  prove  that  the  results  guaranteed  by  the  algorithmic 
description  may  be  understood  In  terms  of  some  simply  stated  properties.  The  square 
root  instruction  Is  the  most  interesting  example  in  this  area,  and  we  have  focused  most 
of  our  attention  on  proving  just  the  simple  property  that  the  effect  of  the  square  root 
Instruction  as  described  by  the  algorithmic  description  does  indeed  compute  the  largest 
floating  point  number  whose  square  is  not  greater  than  the  original  number.  We  felt  this 
example  would  expose  the  hardest  issues  first  and  provide  some  chance  that  the  rest  of 
the  proof  would  be  comparatively  easy.  We  have  not  yet  determined  whether  this 
strategy  will  be  successful. 

At  the  same  time,  we  have  been  concerned  that  the  mechanics  of  carrying  out  a 
complete  proof  should  be  well  understood.  Accordingly,  we  have  hedged  our  bets  a  bit 
and  constructed  a  very  small  fictitious  example  of  a  microcoded  machine,  written  the 
microcode  to  implement  a  simple  instruction  set  for  that  machine,  and  prepared  a 
complete  proof.  We  call  the  machine  the  "TOY"  machine. 

This  chapter  details  the  proofs  for  both  of  these  examples.  To  give  the  flavor  of  a 
complete  proof,  we  present  the  TOY  machine  first. 

3.1  THE  TOY  MACHINE 

The  TOY  machine  Is  a  simple  microprogrammed  machine.  We  have  provided  a  formal 
description  of  Its  target  Instruction  sat  and  of  its  host  architecture.  We  have  written 
the  microcode  for  the  host  level  that  Implements  the  target  instruction  set,  and  we  have 
specified  the  states  in  the  host  and  target  levels  that  correspond  to  esch  other.  Finally, 
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wo  have  written  a  set  of  commands  for  the  proofchecker  to  guide  It  toward  proving  that 
when  the  microcode  runs  on  the  host  machine,  It  correctly  Implements  the  target 
Instruction  set.  For  a  problem  this  simple,  the  commands  to  the  proofchecker  are  entirely 
devoted  to  setting  up  the  proof.  The  actual  details  are  carried  out  completely 
automatically. 

The  TARGET  Machine 

In  order  to  keep  this  experiment  simple,  but  still  deal  with  a  realistic  machine,  we 
designed  the  TARGET  machine  according  to  the  following  requirements: 

■  4K-word  1 0-blt  memory 

-a  12-bit  program  counter,  a  18-blt  accumulator,  and  a  10-bit  Instruct 
register 

-  Infinite  indirect  addressing 

-  six  possible  operations:  add,  subtract,  store,  load,  skip  or  negative,  Jump. 

We  decided  on  the  following  word  format: 


15  13  12  11 

♦ - - - 

I  I  ! 

I  0PC00E  |IND  | 

I  I  I 


TOY  starts  operating  by  fetching  the  instruction  from  location  1  In  memory.  It  proceeds 
by  repeating  the  cycle  of  execution  and  fetching. 

Fetching  Is  performed  as  follows:  the  machine  loads  the  Instruction  register  from  the 
memory  location  that  the  program  counter  points  to;  while  the  Indirect  bit  is  set,  the  1 3 
,  least  significant  bits  of  the  Instruction  register  are  overwritten  by  the  contents  of  the 
memory  location  that  the  effective  address  (EA)  points  to;  then  the  program  counter  Is 
Incremented. 

The  execution  performs  one  of  the  following  operations  according  to  the  3-blt  opcode: 
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add  MEM[EA]  to  the  accumulator;  subtract  MEM[EA]  from  the  accumulator;  load  the 
accumulator  with  MEM[EA];  store  the  contents  of  the  accumulator  In  MEM[EA];  skip  the 
next  operation  if  the  most  significant  bit  of  the  accumulator  la  one  (negative 
accumulate);  jump  to  EA. 

The  precise  ISPS  description  of  the  TARGET  machine  was  written  according  to  the 
English  description  and  is  shown  in  Figure  3-1.  The  ISPS  program  is  divided  Into  the 
following  declarations:  the  memory;  the  registers;  the  fetching  algorithm;  the  execution 
algorithm;  the  main  cycle. 

The  markings  we  selected  In  the  TARGET  machine  are  the  labels  MAIN,  XFETCH,  FLOOR, 
and  EXEC.  The  paths  that  the  algorithm  found  were  one  from  MAIN  to  FETCH,  one  from 
FETCH  to  FLOOP,  one  from  FLOOP  to  FLOOP,  one  from  FIOOP  to  EXEC,  nine  from  EXEC  to 
FETCH. 

MacroPC  is  a  dummy  place  that  holds  the  control  state  (the  label)  and  TlnvReg  covers 
the  internal  registers.  The  complete  set  of  SOs  that  the  ISPS  to  SD  algorithm  found  is 
shown  In  Figure  3-2.  Let  us  look  closer,  for  example,  at  the  third  SD:  it  describes  the 
path  from  FLOOP  to  EXEC  which  Is  denoted  by  .MacroPC»FLOOP  In  the  pre:  and 
#MacroPC=EXEC  In  the  post:.  The  pro:  also  includes  .IR<12>*0,  which  Is  the  precondition 
for  taking  this  particular  path.  The  post:  Includes  also  the  new  value  of  PC,  .PC+1. 

The  HOST  Machine  and  the  Microcode 

The  HOST  machine  Is  the  actual  hardware  that  implements  the  TOY  machine.  Because 
the  goal  of  this  experiment  is  microprogram  verification,  we  chose  a  microprogrammed 
HOST.  The  HOST  machine  was  somewhat  tailored  to  the  TARGET,  for  simplicity,  but  still 
much  generality  and  extendability  were  maintained.  The  description  of  the  HOST  machine 
explicates  all  the  details  of  registers,  combination  circuits,  and  data  paths. 

•We  decided  to  keep  the  microprogram  In  a  64-word  21 -bit  ROM.  ROM  words  contain 
21 -bit  microinstructions  with  the  following  format: 
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TARGET 


BEGIN 

Mi  Memory  Mt 
MEM [0:4kl <15t0> 

Mi  Registers  ** 

PC<11:0>,  !  program  counter 

ACC<15:0>,  !  accumulator 

1R<15:0>,  !  instruction  register 

OPCODE<2:0>  IR<15:13>,  !  operation  code 

EA<11:0>  : -  I R<1 1 : 0>  !  effective  address 

Mi  Instruct  ion. Fetching  *»v 
XFETCH  : »  BEGIN 

IR  «•  MEM  [PCI  NEXT 
FL00P1  REPEAT 

FLOOP  DECODE  1R<12>  -> 

BEGIN 

0  LEAVE  FL00P1, 

1  IR<12:0>  -  MEMCEA] 

END 

NEXT  PC  «-  PC  +  1 
END 

Mt  Instruction. Execution  *# 

EXEC  BEGIN 

DECODE  OPCODE  -> 

BEGIN 

0\AOD  j-  ACC  *■  ACC  +  MEM  [EAJ , 

1\SUB  ACC  -  ACC  -  MEMIEA], 

2\STR  MEMCEA]  -  ACC, 

3NL0A0  ACC  ».  MEMCEA], 

4\SKPN  i-  IF  ACC<15>  ->  PC  •-  PC  +  1, 
5\JMP  PC  *-  EA, 

6  NO. OP  0. 

7  i-  NO. OP  C) 

ENO 

END 

Mr  Execution. Cycle  Mi 
CYCLE  IMA  INI  BEGIN 

PC4-1  NEXT 
REPEAT 

BEGIN 

XFETCH 0  NEXT 
EXECO 
END 
END 
END 


!  program  counter  init 

I  cal  I  fetch  algorithm 
I  call  execution  algorithm 


Figure  3-1:  ISPS  description  of  the  TARGET  machine 
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c CSD  (pres  (.HacroPC) -HAIN) 

(mod:  TlnvReg  HacroPC  PC) 

(anv: ) 

(post:  WlacroPC-XFETCH  #PC-1 (12) ) ) 

(SO  (pre:  (.HacroPC) -XFETCH) 

(mod:  TJnvReg  HacroPC  IR) 

(env: ) 

(post:  AHacroPC-FLOOP  #IR.(D0T  (UORDS  MEH  .PC  .PC) 

(SD  (pre:  (.HacroPC) -FL00P 

(NZEROP  (USEQL  (DOT  (BITS  IR  12)) 

B))) 

(mod:  TlnvReg  HacroPC  PC) 

(env: ) 

(post:  AHacroPC-EXEC  APC-(BITPLUS  .PC  1(12)))) 

(SO  (pre:  (.HacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13))) 

8))) 

(mod:  TlnvReg  HacroPC  ACC) 

(env: ) 

(post:  AHacroPC-XFETCH  AACC-(BITPLUS 
•  ACC 

(DOT  (UOROS  HEH  (USSUB  .IR  11  0) 

(USSUB  .IR  11  8) 

(SO  (pre:  (.HacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

1))) 

(mod:  TlnvReg  HacroPC  ACC) 

(env:) 

(post:  AHacroPC-XFETCH  AACC-(BITPLUS 
.ACC 

(BITHINUS  (DOT  (UORDS  HEH 

(USSUB  .IR  11  8) 

(USSUB  .IR  11  8) 

(SO  (pre:  (.HacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13)))' 

2) ) ) 

(mod:  TlnvReg  HacroPC 

(UORDS  HEH  (DOT  (BITS  IR  (PAIR  11  0) 

(env: ) 

(post:  AHacroPC-XFETCH  A (UORDS  HEH 

(USSUB  .IR  11  8) 

(ussub  .ir  u  en-(.ACC))) 

ISO  (pre:  (.HacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

3))) 

(mod:  TlnvReg  HacroPC  ACC) 

(env: ) 

(post:  AHacroPC-XFETCH  AACC- (DOT  (UORDS  HEH 

(USSUB  .IR  11  0) 
(USSUB  .IR  11  81 

Figure  3-2:  The  SD  description  of  the  TARGET 
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(SO  (pres  (.flacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13))) 

4)) 

(NZEROP  (DOT  (BITS  ACC  IS) 

(mods  TInvReg  flacroPC  PC) 

(anvs ) 

(posts  AtlacroPC-XFETCH  *PC-(BITPLUS  .PC  1(12)))) 
(SO  (pres  (.flacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

4)  ) 

-(NZEROP  (DOT  (BITS  ACC  15) 

(mods  TInvReg  flacroPC) 

(envs ) 

(posts  AflacroPC-XFETCH) ) 

(SO  (pres  (.flacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13))) 

5) )) 

(mods  TInvReg  flacroPC  PC) 

(envs ) 

(posts  ttlaeroPC-XFETCH  #PC- (USSU6  .IR  11  0))) 

(SO  (pres  (.f1acroPC)-EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

6) )) 

(mods  TInvReg  flacroPC) 

(envs ) 

(posts  «1acr oPC-XFETCH) ) 

(SO  (pres  (.flacroPC). EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

7))) 

(mods  TInvReg  flacroPC) 

(envs) 

(posts  WlacroPC-XFETCH) ) 

(SO  (pres  (.flacroPC) -FL00P 

(NZEROP  (USEQL  (DOT  (BITS  IR  12)) 

1))) 

(mods  TInvReg  flacroPC  IR) 

(envs ) 

(posts  WlacroPC-FLOOP  #IR-(USC0NC 
(USSUB  .IR  15  13) 

(USSUB  (DOT  (UORDS  MEM  (USSUB  . IR  11  0) 
(USSUB  .IR  11  0))) 

12  B) 


Figure  2.  (continued) 
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19  18  16  15  13  12  11  9  8  6  5  0 

I  I  I  I  I  I  I  I  I  I 

|  |  MUX  |  |  ALU  |  |  HD  |  LATCH  |  MPC  |  HHEXT  | 

I  I  I  I  I  I  I  t  I  I 

♦ — - - + - +. - - + - ♦ - + - + 

The  HOST  machine  (see  schematic  in  Figure  3-3)  Includes  the  following:  two  memories, 
STORE,  and  ROM;  registers  R1,  R2,  R3,  MAD,  MPC  (microprogram  counter)  and  Ml 
(microinstruction  register);  combinational  circuits  ALU,  MD,  and  MUX;  data  paths;  the 
scanner.  R1  holds  the  value  from  the  ALU  that  receives  its  value  either  from  STORE  or 
from  R1;  R2  holds  the  value  from  R3  or  increments  Its  old  value;  R3  holds  the  value  from 
MD  that  receives  its  value  from  STORE  or  R3;  MAD  holds  the  value  from  MUX  that 
receives  its  value  either  from  R2  or  R3. 

The  HOST  repeats  the  cycle  of  loading  the  microinstruction  register  from  the  location  in 
ROM  that  the  microprogram  counter  points  to;  incrementing  the  microprogram  counter;  and 
scanning  the  microinstruction  and  decoding  a  field  at  a  time.  The  scanner  sends  signals 
that  establish  data  paths  and  latch  values  Into  registers.  It  also  receives  values  from 
registers. 

The  precise  ISPS  description  of  the  HOST  machine  Is  shown  in  Figure  3-4,  and  the 
description  of  the  ROM  in  Figure  3-5.  The  description  of  the  HOST  includes  the  following 
declarations:  the  memories;  the  registers;  the  combinational  logic;  and  the  execution 
cycle  that  fetches  and  scans  the  IR.  The  microprogram  is  specified  as  a  set  of 
assignments  to  ROM.  The  comment  in  each  assignment  shows  the  microinstruction  In  a 
mnemonic  form:  The  nonzero  fields  of  each  microinstruction  are  separated  by  ®.  The 
mnemonics  correspond  to  the  ones  in  the  DECODE  statements  In  Figure  3-4.  For  example, 

MUXR3@LMADGONIND810  means  that  MUX  ■  3,  ALU  ■  0,  MD  •  0,  LATCH  *  6,  MPC  ■  2  and 
MNEXT  *  10. 

The  first  phase  of  the  proof  converts  the  ISPS  description  of  the  HOST  Into  a  single  SD 
whose  postt  field  Includes  the  complete  representation  of  the  HOST.  This  SD  is  used  In 
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MICROCODE  VERIFICATION 


Figure  3-3:  Schematic  of  the  TOY  Host 
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HOST  i 


-  BEGIN 


ft*  Memory  ft* 

ROM [0:631 <20: 0>. 
STORE  [0:4k] <15: 0> 


ft*  Registers  *ft 
MPC<5:0>. 

MI<20:0>, 

MNEXT<5:0>  :-  Ml<5:0>, 
R1<1S:0>. 

R2<11:0>. 

R3<15:0>, 

MAO<11:0> 

ft*  Combinational .Circu 
ALU<1S:0>, 

MUX<11:0>, 

MD<1S:0> 

*ft  Execu t i on. Cyc I e  ft* 

CYCLE  IMA INI  :-  BEGIN 
REPEAT 
BEGIN 
MI  ^  ROM  [MPC1  NEXT 
MPC  *•  MPC  ♦  l 
NEXT 

DECODE  MI<19:18>  -> 
BEGIN 

0  :•  NO. OP  O, 
1  NO. OP  0. 
2XMUXR2  i-  MUX 
3NMUXR3  «-  MUX 
END  NEXT 

DECODE  MI <16: 15>  -> 
BEGIN 
0  NO. OP 
1 \ALUNOP  : ' 

2 \ ALU ADO  : 
3XALUSUB  : 

END  NEXT 


!  micro  program  counter 
!  micro  instruction  register 
!  next  micro  instruction 
!  Accumulator 
I  Program  Counter 
!  Instruction  Register 
!  memory  address 

ts  ft* 

!  arithmetic,  logic  unit 
!  memory  address  multiplexer 
!  memory  data  multiplexer 


R2<11:0>. 

R3<11«0> 


0, 

ALU  •-  STORE  [MA01, 

ALU  R1  ♦  STORE  tMAOl . 
ALU  R1  -  STORE  [MADJ 


OECOOE  MI <13: 12>  -> 

BEGIN 

0  NO. OP  0. 

1  NO. OP  O. 

2\ALL  i-  MO  •-  STORE  [MADJ, 

3\AD0  :■  MO  ►  R3<15»13>  STORE  [MADJ  <12  »0>- 
ENO  NEXT 

Flour*  3-4:  ISPS  description  of  the  HOST 


ai 


mm 


DECODE  ni<ll:9>  -> 

BEGIN 

0  t-  NO. OP  0. 

1NLR1  <■  R1  <-  ALU, 

2\LR2  *  ■  R2  *■  R3<11:0>, 

3\LR3  R3  «-  M0, 

4MNCR2  R2  «•  R2  +  1, 

5MJRITE  j-  STORE [MAD]  Rl, 
S\U1AD  »•  MAD  «■  MUX, 

7MNIT  !-  R2  «-  1 
END  NEXT 


OECODE  (II  <8: G>  -> 

BEGIN 

0  NO. OP  (), 

1X0NP0S  tm  IF  NOT  R1<1S>  ->  MPC  MNEXT, 
2N0NIND  IF  R3 <12>  ->  MPC  •-  MNEXT, 

3  NO. OP  0. 

4\NXT  MPC  -  MNEXT, 

S  NO. OP  0, 

G  NO. OP  {), 

7\0N0P  i-  MPC  «-  R3<15t  13> 

END 

ENO 

END 


Figure  4.  (continued) 


a  2 


Ron  t- 

BEGIN 

*»v  Memory  vwr 

ROM [0:63] <20: 0> 

ft*  Execution. Cycle  ** 

CYCLE  IMA IN) 

BEGIN 

ROM [0]  4.  #0201410  ;  I  ALUA00eLRleNXTe8 

ROM [1]  ».  #0301410  ;  !  ALUSUBaLRleNXTeS 

ROM  (21  4.  #0005410  ;  •  URJTEeNXTa8 

ROM  13]  4.  #0101410  j  !  ALUN0PaLRlaNXTa8 

ROM  (41  4.  #0000416  ;  !  NXT#14 

ROM  tSI  4.  #0002410  5  !  LR2«NXTe8 

ROM  [61  4.  #0000410  ;  !  NXTe8 

ROM  [7]  #0000410  ;  !  NXT«8 

ROM  [81  #2005000  j  !  FETCH:  MUXR2aLMAO 

ROM  191  -  #0023413  ;  •  ALL*LR3eNXTell 

ROM  [10]  4.  #0033000  ;  !  ADD«LR3 

ROM  [11]  4.  #3006212  $  !  FLOOP:  MUXR3eLM AOeON I NDel 0 

R0MC121  4.  #0004000  t  !  EXEC:  INCR2 
ROM  [13]  4.  #0000700  ;  !  ONOPeB 

ROM  [14]  *•  #0000110  ;  !  0NP0S«8 

ROM [15]  <-  #0004410  I  !  INCR2aNXTa8 
ROM [16]  4.  #0007410  !  INITeNXTe8 

NEXT  EXEC  NO. OP  0 

ENO 


Figure  3-5:  The  specification  of  the  Microcode 


the  next  section  as  the  specification  of  the  control  state  of  the  HOST  In  the  mapping. 
The  ISPS  description  of  the  microcode  is  converted  to  SD  notation  too. 

The  current  implementation  requires  that  the  ISPS  description  of  the  HOST  consist  of  a 
single  cycle,  for  reasons  of  simplicity.  The  HOST  will  indeed  usually  be  a  single  cycle 
because  it  represents  hardware.  Minor  implementation  changes  will  accommodate 
arbitrary  ISPS  descriptions  of  the  HOST. 

The  next  section  Introduces  the  mapping  and  the  following  section  explains  how  the 
symbolic  simulation  of  the  TARGET  by  the  microprogrammed  HOST  machine  is  set  up  and 
performed. 

Relating  the  TARGET  and  the  HOST 

In  order  to  show  that  one  machine  simulates  another,  a  relation  between  the  two  must  be 
established.  The  relation  addresses  control  issues  and  data  issues.  The  control  part  of 
the  relation  specifies  all  the  pairs  of  control  states  (in  the  TARGET  and  HOST, 
respectively)  that  have  the  following  properties:  whenever  a  control  state  is  reached  in 
one  machine  then  the  corresponding  one  is  reached  in  the  other  machine.  Two  obvious 
pairs  are  the  pair  of  initial  states  and  the  pair  of  final  states.  A  necessary  condition  for 
simulation  (of  terminating  machines)  is  that  corresponding  initial  states  always  lead  to 
corresponding  final  states.  The  data  part  of  the  relation  specifies  the  pairs  of  carriers 
that  should  have  the  same  contents  whenever  a  pair  of  control  states  is  reached.  This 
data  relation  Is  celled  a  covering. 

The  control  states  In  the  TARGET  machine  to  be  mapped  from  or  to  were  selected  as  the 
set  of  all  the  markings.  For  the  particular  TOY  machine  example  the  following  markings 
were  selected:  the  initial  state  Is  MAIN;  the  top  of  the  main  cycle  is  XFETCH;  the  infinite 
fetch  loop  Is  broken  at  FLOOP;  the  fetch  algorithm  is  separated  from  the  execution 
algorithm  at  all  the  control  states  in  the  TARGET  map  to  or  from  a  state  described  by  the 
top  of  cycle  of  the  HOST  and  an  additional  predicate  (usually  the  value  of  the 
microprogram  counter). 

The  top  of  Figure  3-6  shows  a  set  of  control'relatlonss  the  first  element  of  each  Is  a 
marking  (represented  by  an  ISPS  label)  In  the  TARGET  and  the  rest  Is  a  predicate  that 
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together  with  the  code  of  the  HOST  makes  up  Its  control  state.  The  bottom  of  Figure  3-6 
shows  the  coverings  that  specify  the  relation  between  registers  (or  memories)  In  the 
TARGET  to  registers  (or  memories)  In  the  HOST. 

During  the  first  phase  of  the  proof,  a  set  of  Internal  MAPPING  records  is  generated  from 
the  concise  representation  of  Figure  3-6.  Figure  3-7  shows  two  out  of  the  eight 
mappings.  A  MAPPING  record  has  three  fields:  from:,  that  specifies  the  control  state  of 
either  the  TARGET  or  the  HOST;  to:,  that  specifies  the  corresponding  control  state  of  the 
other  machine;  and  map:,  that  specifies  the  covering.  The  notion  of  MAPPING  records  Is 
built  Into  the  SD  proofchecker  and  Is  used  in  the  second  phase. 

We  have  described  the  TARGET,  the  HOST+microcode,  and  the  relation  between  them  in 
three  forms:  English,  formal,  and  a  form  that  can  be  processed  by  the  SD  proofchecker. 
The  first  phase  of  the  proof  generated  the  batch  of  SD  commands  from  the  formal 
descriptions. 

Symbolic  Simulation 

The  previous  sections  presented  the  TARGET  machine,  the  HOST  machine  with  Its 
microprogram,  and  the  mapping  between  the  machines.  This  section  shows  how  the  proof 
of  simulation  of  the  TARGET  by  the  HOST  with  respect  to  the  mapping  was  performed 
using  the  SD  command  batch.  The  simulation  is  performed  within  the  state  delta  symbolic 
execution  framework,  thus  It  Is  called  symbolic  simulation. 

The  SD  proof  system  operates  by  maintaining  a  "current  state"  of  the  execution,  which 
can  be  manipulated  by  opening  or  closing  proofs,  or  by  applying  SDs  or  mappings.  A  SD  is 
a  nototlon  for  specifying  a  segment  of  execution,  either  as  the  "goal"  or  for  changing 
the  current  state.  A  SD  has  4  fields:  pro:,  mod:,  env:,  and  post:.  When  a  SD  Is  used  to 
Open  a  proof,  then  the  pre:  Is  added  to  the  current  state  and  the  post:  becomes  the 
goal;  when  It  Is  being  "applied",  then  the  pre:  must  be  true  in  the  current  state,  and  the 
effect  of  the  SD  Is  removing  from  the  current  state  everything  that  depends  on  mod:  and 
adding  post:.  A  MAPPING  has  three  fields:  from:,  to.-,  and  map.  When  a  mapping  Is 
"applied",  its  from.-  must  be  true  in  the  current  state,  and  the  effect  of  the  mapping  Is 
adding  (o;  and  map:  to  the  current  state. 


((MAIN  (.MPCM6) 

(XFETCH  (,MPC)-8) 

(FLOOP  (.MPCi-ll) 

(EXEC  (.HPO-13  (.MADMUSSUB  ,R3  11  0))) 


((Covering  MEM  «ST0RE  IB  1S») 

(Covering  PC  <<R2  12>>) 

(Covering  ACC  <<R1  16>>) 

(Covering  IR  «R3  1B>>) 

(Covering  MacroPC  «MicroPC  2>  <MPC  G») 

(Covering  HJnvReg  «MI  21>  <MAD  12>  <ALU  1B>  <MUX  12>  <MD  1B») 
(Covering  TInvReg  «HInvReg  22»)) 


Figure  3-6:  Mapping  between  TARGET  and  HOST 


36 


(HAPPING  (from:  (.MPC) -11 
(SD  (pre:) 

(mod:  HicroPC  HI) 

(env:  MicroPC) 

(post:  #MI-(00T  WORDS  ROM  .MPC)) 

(TR  ( (SEQ  (USSET  MPC  *) 

(DECODE  *  *  t  S  S) 
(DECODE  S  S  t  *  «) 
(DECODE  t  S  t  S  *) 
(DECODE  ttfStttt 
«) 

(DECODE  tttttttt 

•)) 

(REPEAT  t) 

(ProcMark  HOST! 

(to:  (.MacroPO-FLOOP) 

(map:  (.MEM) -(.STORE) 

(.PC)-(.R2) 

(.ACC) « (.Rl) 

(.IR)-(.R3))) 

(MAPPING  (from:  (.MacroPO-EXEC) 

(to:  (.MPC) -13  (.MAD)-(USSUB  .R3  11  0) 


(SO  (pre:) 

(mod:  MicroPC  MI) 

(env:  MicroPC) 

(post:  «1I-(D0T  (UORDS  ROM  .MPC)) 
(TR  ((SEQ  (USSET  MPC  *) 


(DECODE  S 
(DECODE  I 
(DECODE  * 
(DECODE  S 
(DECODE  I  t 
(REPEAT  *) 
(ProcMark  HOST] 


(map:  (.STORE) -(.MEM) 
(,R2)-(.PC) 
(.Rl)-(.ACC) 
(.R3) • (. IR) ) ) 


t) 

S) 

t) 

t  t  S  I  •) 
t  I  t  t)l 


Figure  3-7:  Two  of  the  MAPPING  records 
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firpiro  3-U  shows  an  outline  of  Hie  hatch  of  commands  that  drives  the  proof  in  the 
second  phase.  7ha  first  Open  and  NewDeco/nposition  declare  the  memories  and 
registers  in  the  HOST  machine.  The  pro:  of  the  second  Open  includes  the  microcode  and 
the  mapping  between  the  TARGET  and  the  HOST.  The  post:  of  the  same  command  includes 
tin;  set  of  SDr;  that  describes  the  TARGET  machine.  Executing  this  command  adds  the 
microcode  and  mapping  to  the  current  state  and  makes  the  TARGET  the  "goal".  A 
seguonce  of  seven  NcwComposition  commands  declares  the  memories  and  registers  in 
tho  lARGi.f  machine  and  their  relation  to  the  places  in  the  HOST.  The  command 
fiymSimi/loto  performs  the  symbolic  simulation  according  to  a  heuristic  that  we  have 
developed. 

Iho  SymSimuliite  command  executes  a  heuristic  that  drives  the  symbolic  simulation.  For 
each  SI)  in  lit.?  "goal"  do  the  following:  open  tho  SD;  apply  a  mapping  from  the  TARGET  to 
the  HOST;  symbolically  execute  (i.e.,  keep  applying  SDs)  until  the  state  can  be  mapped 
hack  to  the  TARGET;  apply  the  mapping  to  the  TARGET;  close  the  SD.  Finally  close  the 
whole  "«kmI". 

The  combined  effect  of  the  two  phases  of  the  proof  Is  the  generation  of  a  set  of  SDs 
from  the  TARGET  using  symbolic  execution  of  the  TARGET  and  proving  these  SDs  by  using 
symbolic  execution  of  tho  HOST  and  microcode.  The  rest  of  the  effort  is  setting  up  the 
right  relations  among  tho  registers  and  memories  and  between  the  HOST  and  TARGET  to 
assure  integrity  of  tho  proof.  Note  that  tho  only  input  needed  is  the  ISPS  description  of 
the  TARGET ,  HOST,  and  ROM  and  the  concise  representation  of  the  mapping  between  the 
machines.  The  rest  is  done  automatically. 

3.2  THE  FT  SC 

The  /  I  SC  was  chosen  as  the  real  example  on  which  to  try  out  the  microcode  verification 
system  because  it  is  a  general-purpose  computer  witli  enough  features  to  thoroughly 
test  the  system;  in  addition,  it  is  still  in  the  development  stage,  so  that  successful 
verification  or  discovery  of  bugs  would  influence  the  final  version. 

Some  of  the  characteristics  of  the  FTSC  («s  of  May  1970)  are: 
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(  (Open  (v.ir: 

(SO 


1 1  J  •  '!.[  Il  'I.OIKp 

[Op'-n  ( Vcir 

(GD 


Mi  err, PC  EXP  MD  MUX  ALU  HAD  R3  R2  R1  HI  MPC  STORE  ROM  UNDEFINED 
CLL’l.OCiV  LABLOCi'i  ASSLDC&  ARRLQC&) 

(pre:  (Covering  OMEGA 

«(1icroPC  l>  <EXP  440>  <MD  16>  <MUX  12> 

<ALU  1C>  <MAD  12>  <R3  16>  <R2  12>  <R1  18> 

<;il  21  >  <I1PC  G>  <ST0RE  16  10801Q> 

<nuri  21  1  !)<)□>  <UMDEF  1  NED  440>  <ClKL0C&  44Q> 
<LADLUCi  44Q>  <ASS10CS  44Q>  <ARRL0C«  44Q»)) 

( wr.fi  s  CiiiCGA) 

(i.'iiv; ) 

(pest:))) 

[.r, i  lion  (Cover  i ny  OMEGA 

«HicroPC  1>  <EXP  44Q>  <HD  16>  <MUX  12> 

<ALU  16>  <HA0  12>  <R3  1G>  <R2  12>  <R1  1G> 

<M1  21  >  <MPC  G>  <ST0RE  1G  10001Q> 

<R0:i  21  100Q>  UNDEFINED  44Q>  <CLKLOC&  44D> 
<LASLCCS  44Q>  <ASSL0C&  44Q>  <ARRL0C&  44Q»)) 
o;  MicrorC  EXP  IP,  ACC  PC  HEM  UNDEFINED  CLKL0C&  LABL0C&  ASSLOC& 
ARRLCCili 

Ipre:  (DOT  (WORDS  ROD  0D  =  (OCONST  2B1410Q  21) 


.  Ill  Specification  of  microcode  III 

(MAPPING  (from;  (.ttacroPCNMAIN) 

Itos  (.f1PC)-lG 
(SD  (pres) 

(mods  HicroPC  Ml) 

(envs  MicroPC) 

(posts  #f1 1 ■  (DOT  (WORDS  ROM  ,MPC)) 

(TR  ((SEQ  (USSET  MFC  8) 

(DECODE  8  8  8  8  8) 

(DECODE  88888) 

(DECODE  88888) 

(DECODE  888888888) 
(DECODE  888888888)) 
(REPEAT  8) 

(ProcMark  HOST) 

(maps  (.STORE)-(.MEn) 

(,R2)» (.PC) 

(.Rl )  -  (.ACC) 

(.R3)-(.IR))) 

.  Ill  All  mappings  1 1 1 


Figure  9*8:  Outlines  of  tho  command  batch 
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(cnv: ) 

(pouts  (SD  (pres  (.MacroPC) -MAIN) 

(mod:  TInvReg  flacroPC  PC) 

(env: ) 

(post:  /tflacroPC-XFETCH  #PC«1(12))) 

....  Ilf  State  Delta  representation  of  TARGET  III 

((••.■uCompoo  i  t  i  on  (Covering  MEM  <<ST0RE  1G  1G>>) ) 

(tJfi.Compo'.' i  t  i on  (Covering  PC  <<R2  12>>)) 

(Ht’iiCompoo  i  t  i  on  (Covering  ACC  <<R1  1G>>)) 

(McuCoi.ipos i  t  i on  (Covering  IR  <<R3  16>>)) 

(’j'.’iiCciripo''.  i  t  i  on  (Covering  MacroPC  <<!1icroPC  2>  <f1PC  G>>)) 

(tJi'tiCompo:.  i  t  i  on  (Covering  HlnvReg 

«MI  2i>  <MAD  12>  <ALU  1G>  <(1UX  12>  <MD  16») ) 
(fJeiiCoMpor.  i  t  i  on  (Covering  TlnvRcy  «H!nvReg  22>>)) 

(Gi (i.rj  i  mu  late) ) 


Figure  8.  (continued) 


-112  instructions,  including  integer,  flouting  point,  and  vector  operations 

-  data  formats:  fixod  point  (32-liit,  two's  complement  integer)  and  floating 
point  (24-bit,  two's  complement  mantissa;  8-bit,  two's  complement 
exponent) 

-  0  address  modus 

-  ii  general-purpose  registers  (that  survo  as  accumulators,  index  registers, 
or  address  pointers)  and  8  working  registers 

-  1 0  interrupt  levels 

-  OIK  of  addrossablo  program  memory 

Thu  first  stop  in  the  verification  process  is  writing  the  formal  host  and  target  machine 
descriptions  in  ISPS.  Ideally,  the  designer  of  the  machine  would  write  the  formal 
description  along  with  the  informal  description  ("user's  manual").  In  lieu  of  this,  the 
writer  of  the  formal  descriptions  must  submit  them  to  the  designer  for  "description 
verification"  (that  this  is  really  the  machine  informally  described  in  the  manual)  before 
proceeding  with  the  proof.  In  addition,  the  writer  of  the  formal  descriptions  may  discover 
"bugs"  (inconsistencies  or  incompleteness)  in  the  user  manual.  As  a  formal  description  is 
being  written,  its  writer  will  probably  be  in  need  of  information  which  was  either  omitted 
from  the  machine  user  manual  or  presented  there  in  an  ambiguous  or  contradictory  way. 

Our  experience  yieldod  approximately  120  questions  on  the  documentation,  accumulated 
over  a  period  of  about  six  months.  Approximately  80  answers  were  finally  obtained  from 
various  persons  who  had  "insido"  information  about  the  construction  of  t-he  FTSC. 
Typical  difficulties  arc  missing  information,  multiple  names  for  the  same  value,  e.g., 
AMOOH  and  AM,  and  inconsistencies  between  written  and  diagrammed  specifications. 

As  explained  earlier,  wo  consider  the  total  problem  of  microcode  verification  as 
consisting  of  two  parts:  tho  proof  that  tho  host  machine  with  its  microcode  implements 
tho  target  machine  (as  described  in  a  language  containing  only  those  operations 
available  to  tho  host)  and  the  proof  that  tho  target  machine,  Instruction  by  instruction, 
satisfies  some  higher  level  specification.  For  example,  the  target  machine  description  of 
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tlio  integer  multiply  and  divide  instructions,  and  all  floating  point  instructions,  would  most 
likely  consist  of  an  algorithm  using  the  host  machines  operations  of  shifting,  testing, 
adding,  XORing,  etc.  The  higher  lovfel  specification  would  be  that  these  instructions  do  in 
fact  find  the  product,  quotient,  otc.  to  a  givon  precision.  The  instruction  definitions  given 
in  the  user  manual,  which  are  largely  English,  are  most  likely  those  instructions  needing 
this  second  lovol  of  proof. 

All  of  our  work  to  dote  on  the  verification  of  the  FTSC  has  been  concerned  with  the  step 
from  the  target  to  the  higher  specification.  This  seemed  a  wise  choice,  since  we  knew 
that  at  the  start  of  our  project  the  FTSC  host  machine  design  was  not  finalized,  although 
the  target  machine  would  remain  more  or  less  the  some.  In  addition,  many  aspects  of  the 
system  had  to  be  developed  before  o  truly  largo  example  could  be  attacked. 

Tim  particular  instruction  chosen  was  square  root.  Square  root  was  chosen  because  of 
tlio  relative  compactness  of  its  algorithmic  description  in  the  target  machine,  and  the 
wide  difference  between  the  algorithm  and  its  higher  specification.  Although  the 
second-level  verification  has  nothing  to  do  with  the  microcode  or  the  host  machine,  one 
characteristic  making  it  loss  than  general  program  verification  is  that  the  data  types 
used  in  tlm  target  and  higher  lovol  descriptions  are  usually  restricted  to  be  bitstrings 
and  integers  in  thn  target,  and  values  of  bitstrings  and  reals  in  the  higher  level.  Thus  we 
used  the  square  root  instruction  as  a  testing  ground  for  developing  the  automatic 
simplification  of  expressions  in  these  data  types. 

The  status  of  our  work  on  the  square  root  algorithm  Is  that  the  simplifier  Is  able  to  handle 
automatically  all  the  derivations  noedod  to  complete  the  proof  of  correctness.  Smoothing 
the  user  interface  and  gracefully  setting  up  the  induction  needed  for  the  loop  remain  to 
bo  done. 

It  is  hoped  that  many  of  the  special  simplfication  rules  adopted  in  proving  the  square  root 
will  also  ho  useful  in  the  other  proofs  of  higher  level  correctness. 

Square  Root  Proof 

In  this  section  we  give  the  ISPS  version  of  jthe  algorithm  that  constitutes  the  FTSC 
target  machino  description  of  the  floating  point  square  root  instruction  (SRTF)*  See 


Figure  3-0.  This  description  of  the  algorithm  was  written  on  tha  basis  of  the  microcode 
flowchart,  which  is  derived  diroctly  from  the  host  description  and  the  microcode.  Then 
wo  show  tho  derivations  the  simplifier  is  able  to  accomplish  automatically  in  proving  that 
SHTF  finds  tho  square  root  to  within  a  certain  accuracy. 

Lot  us  "talk  through"  tho  algorithm  now:  Tho  first  lino  decides  if  the  input  is  to  be  from 
register  GPXHA  or  rogistor  MD.  If  tho  input  is  negative,  the  algorithm  is  terminated  with 
overflow  flag  sot.  If  the  input  is  0.  tho  algorithm  is  terminated  with  output  register 
C PXIil J  sot  to  the  floating  representation  of  0.  From  here  on  the  algorithm  splits  Into  two 
parts:  tho  calculation  of  the  now  exponent  and  the  calculation  of  the  new  mantissa.  The 
exponent  calculation  splits  depending  on  whether  it  is  even  or  odd.  If  the  old  value  Is 
ovon.  tho  now  exponent  is  half  tho  old  vaiuo.  If  the  old  value  Is  odd,  It  Is  made  even  by 
adding  1  ami  shifting  the  mantissa  accordingly  (in  the  even  case  the  mantissa  Is  shifted 
two  hits:  in  the  odd  case,  only  one  bit).  Now  the  new  value  is  half  the  old  value  (with  a 
chock  for  exponent  overflow  thrown  in).  The  mantissa  is  now  calculated  by  a  variation 
of  the  longhand  high  school  square  root  algorithm.  The  mantissa  is  shifted  two  bits  at  a 
tune  through  the  loop  23  times.  The  loop  has  two  branches  according  to  the  sign  of  the 
"remainder,"  the  register  SUM. 

The  theorem  which  expresses  the  correctness  of  SRTF  is 

Theorem:  If  FL(INPUT)=x*0,  then  SRTF  terminates  with  Fl(OUTPUT)2  Sx  S  FL+(OUTPUT)2. 

If  FLONPUTXO,  then  SRTF  terminates  with  0VFF=1. 

Explanation  of  notation:  FL(R)  is  the  value  of  the  bitstring  R  as  a  floating  point  number  In 
tlie  FTSC  format:  24  leftmost  bits  coding  two's  complement  fractional  mantissa  and 
rightmost  3  hits  coding  two's  complement  exponent.  INPUT  is  either  the  register  GPXRA 
or  MO,  depending  on  AMODE.  OUTPUT  is  the  register  GPXRB.  FL*(R)  is  floating  successor 
to  rL(R),  i.c„ 

Fl*(R)  »  (TCVAL(R<3f  :8>)+1 )  *  2TCVAL(R<7!0>**23. 

Letting  MAN(R)  »  TCVAL(R<31 :8>)  *  2*23  and  EXP(R)  ■  TCVAL(R<7:0»,  it  is  sufficient  to 
provo 
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SRTF:  - 


BEGIN 

DECODE  AnODE->(U0-Ul-GPXRA.lJ0-lJl-riO)  NEXT 

IF  WO  LSS  0->  (OVFF*-l  NEXT  LEAVE  SRTF)  NEXT 

IF  U8<31:8>  EQL  0-> (GPXRB-"83  NEXT  LEAVE  SRTF)  NEXT 

U0<31:S>-U0<31:8>  SL0  1  NEXT 

U0<7:0>-0  NEXT 

DECODE  UI<0>a> 

BEGIN 

0:  •  (GPXRB*-U0<31  s  30>  NEXT 
U0-U0  SL0  2  NEXT 
Ul<31:8>-0  NEXT 
Ul<7:0>-Ul<7>sU.l<7: 1>  ), 

1:-(GPXRB-U0<31>  NEXT 
U3-U0  SL0  1  NEXT 
Ul<31:8>-0  NEXT 
EXPOUT-U1  <7>®U1  <7 :  3>  +  1  NEXT 
U1<7:0>-EXPOUT<7:0»  NEXT 
U1<7:0>-141<7>.*141<7:1>  NEXT 
IF  EXP0UT<8>  XOR  EXPOUT<7>->U1<7:0>-#100  ) 
END 

NEXT 

SUIVGPXRB-1  NEXT 
GPXniVGUn<23: 0>«U0<31 s  30>  NlX r 
COUNTER-0  NEXT 
SLOOP: - 

REPEAT 

BEGIN 

COUNTER-COUNTER+1  NEXT 
U0<31 : 8>-U0<31 : 8>  SL0  2  NEXT 
DECODE  SUM<31>-> 

BEGIN 

0:«  (U1 <31 i 8>-2*Ul <31 : 8>  +  1  NEXT 

IF  COUNTER  EQL  23-> (LEAVE  SLOOP)  NEXT 
U2-4*U1<31:8>  ♦  1  NEXT 
SUfl-GPXRB-142  NEXT 
GPXRB-SUM<23: 0>eU0<31: 30>) , 

It-  (U1<31:8>-2*UJ<31:8>  NEXT 

IF  COUNTER  EQL  23-> (LEAVE  SLOOP)  NEXT 
142-4*141  <31 :3>  +  3  NEXT 
SUM-GPXRB+U2  NEXT 
GPXRB-SUN<29i 0>aU0<31 1 30> ) 

END 

END 

NEXT 

CPXRB-U1 

END 


Figure  3-9:  ISPS  description  o<  the  square  root  algorithm 
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(I)  If  EXP(INI'UT)*o  is  ovon  and  MAN(INPUT)*246«ARG,  then  SRTF  terminates  with 
2*EXP(OUTPUT)=e  and  (MAN(OUTPUT)*223)r  S  ARG  S  (MAN(OUTPUT)*223+1  )2,  and 

(II)  If  EXP(INPUT)=e  Is  odd  and  MAN(INPUT)*245  *  ARG,  then  SRTF  terminates  with 
2TXP(OUTPUr)=e+1  and  (MAN(OUTPUT)*223)2  S  ARG  S  (MAN(OUTPUT)*223+1  )2. 

So  the  proof  is  carried  out  by 

(1 )  symbolically  executing  through  the  end  of  the  exponent  calculation  tor 
oven  and  odd  input  exponent,  and  proving  the  relevant  parts  of  (I)  and  (II) 
at  that  point  (noto  that  OUTPUT  is  assigned  the  contents  of  working 
register  W1  at  the  end  of  SRTF); 

(2)  at  that  point,  for  even  input  exponent, 

MAN(INPUT)*246  =  USVAL(GPXRB<1:0>@W0<31:10»*222  *  ARG, 
and  for  odd  exponent, 

MAN(INPUT)*245  =  ARG. 

Thus  to  complete  both  (I)  and  (II)  it  remains  to  show  that 
CLAIM:  TCVAL(OUTPUT<31 :8»2  S  ARG  <TCVAL(OUTPUT<31 :8>*1  )2. 

Hero  is  where  we  use  induction  to  prove  loop  invariants  that  lead  to  a  proof  of  the 
CLAIM.  Let  R  denote  the  contents  of  R  ufier  i  limes  through  the  loop,  that  is,  the  last 

contents  before  COUNTER  changes  from  i  to  i+1. 

The  CLAIM  is  proved  from 

SUUCLAIM:  Fur  1  <i<23.  USVAL(W1(<30:»>):  S  int(ARG*22i-4B)  S  (USVAL(W1,<30:8»+1  )2. 

(The  actual  calculation  with  the  integer  part  function  int  is  done  by  noting  that  if 
X=USVAL(R),  then  int(X*2*k)  «  USVAl(R  SRC)  k).) 

The  CLAIM  is  proved  from  the  SUBCLAIM  by  taking  i«23.  The  SUBCLAIM  is  Implied  by  the 
first  throe  of  the  following  loop  invariants  for  1£i£22.  ((HI)  is  shown  here  for  the  case 
of  ovon  exponent  only). 


(HI )  (2*USVAl(WV<30:8»*1)2  ♦  TCVAL(SUM()  «  USVAL(a<30:8>Q0(23)  SRO  44-20 

(02)  TCVAl(SUM)  <,  4*USVAL(W1  <30:8»  ♦  2 
(03)  -TCVAL(SUM)  <  4«USVAL(W1.<30:8>)  ♦  1 
(H4)  W0_  =us  (q<28:8>0O(11)  SLO  2i) 

(H5)  W1<31  :i*8>  =us  0(24-i) 

(HG)  W2  <31:i^2>  *us  0(30-i) 

(Hr)  SUM(<29:0>  =us  GPXRB<31:2> 

(HO)  SUM(  =TC  GPXRB<31:2> 

(HO)  GPXnB<1:0>  =us  W0.<31:30> 

rtuts  wr  provo  that  if  (H1)-(H9)  arc*  true  for  1  < •< 2 1 ,  then  they  are  true  for  i+1. 
Additional  induction  hypotheses  ((H4)-(H9)  were  found  to  facilitate  the  proof  of 
(HI  )-(H3)).  Then  wo  prove  that  if  the  SUBCLAIM  is  true  for  1SI<22,  then  It  is  true  for  i+1. 
The  simplifier  automatically  carries  out  those  deductions. 

The  following  is  the  batch  containing  the  proof  of  the  square  root  algorithm  as  it  Is  read 
into  MICHOVCR  in  form  to  be  automatically  chucked. ^ 

(BATCHSQRT 
[(InitProof  SOUTM) 

(InstanliotcContents  GPXRA  a) 

(Prove 

[SD  (pro:  (.AM0DE)=0  (TCGEQ  (USSUB  a  31  8) 

0) 

(TCNEQ  (USSUB  a  31  8) 

0) 

(USEQL  (USSUB  a  0  0) 

0) 


Actu.iiiy,  m  the  present  form  of  the  system  the  INVARIANT  end  LABEL  must  be  given  in  expended  form  et  every 
occurrence. 
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(SO  (pre:  (NZEROP  (USEQL  .AMODE  0))) 

(mod:  MicroPC) 

(cnv:  MicroPC) 

(post:  ©Program))) 

(mod:  OMEGA) 

(cnv:  GPXRA) 

(post:  (NZEROP  (REALEOUAL  (PRODUCT  (EXPVAL  #GPXRB) 

2) 

(EXPVAL  a))) 

[NZEROP  (REALLEQ  (POWER  (PRODUCT  (MANVAL  #GPXRB) 

(POWER  2  23)) 

2) 

(PRODUCT  (MANVAL.  a) 

(POWER  2  600] 

(NZEHOP  (REALLEQ  (PRODUCT  (MANVAL  a) 

(POWER  2  5GQ)) 

(POWER  (REALPLUS  (PRODUCT  (MANVAL  #GPXRB) 
(POWER  2  23)) 

1) 

2] 

((ProposcModo  (.COUNTER)*  1 ) 

[ProvcbyCuses  [SD  (pre:) 

(mod:  OMEGA) 

(cnv:  OMEGA) 

(post:  #C0UNTER*(1  ©Invariant) 

(SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER;:(USSUB  (TCPLUS  .COUNTER  1) 
31  0)@Label] 

(((USSUO  .SUM  31  3 1  )*  J 
([ProposeModc  ((.COUNTER)*  1 
and  (SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER=(USSUB 
(TCPLUS  .COUNTER  1) 

31  0)eLebel] 

(Close))) 

((USSUB  .SUM  31  31  )*0 
([ProposeMode  ((.C0UNTEF,)=1 
and  (SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 
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r 


(post:  #COUNTER=(USSUB 
(TCPLUS  .COUNTER  1) 

31  COSLabel] 

(Close] 

[ApplySD  (SO  (pro:  ((USSUB  .SUM  31  31)=1  or  (USSUB  .SUM  31  31)=0)) 
(mod:  OMEGA) 

(onv:  OMEGA) 

(post:  (T  or  T) 

#COUNT£R=1  ©Invariant 


(SO  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER=(USSUB  (TCPLUS  .COUNTER  1) 
31  0)©Label] 


(Provo  [SO  (pro:) 


(mod:) 

(onv:  OMEGA) 

(post:  (,COUNTER)=1  ©Invariant 


(SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(onv:  MicroPC) 

(post:  #COUNTER=(USSUB  (TCPLUS  .COUNTER  1) 

31  0)©Label] 

((ProposoModo))) 

[ProvobyCascs  [SD  (pre:  (NZEROP  (REALLEO  1  .COUNTER)) 

(NZEROP  (REALLEQ  .COUNTER  21  ))©lnvariant 
(SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  //COUNTER=(USSUB  (TCPLUS  .COUNTER  1) 
31  0)QLabol))) 

(mod:  OMEGA) 

(env:) 

(post:  #COUNTER»(RCALPLUS  .COUNTER  Deinvariant 
(SD  (pro:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER=(USSUB  (TCPLUS  .COUNTER  1) 
31  0)©Lobel] 

((((USSUB  .SUM  31  31  )■  I  and  (USSUB  .GPXRB  31  31)«D 
((ProposoModo))) 

(((USSUB  .SUM  31  31)*0  and  (USSUB  .GPXRB  31  31)*0) 
((ProposeMode] 

(Prove  [SD  (pre:  (NZEROP  (REALLEQ  1  .COUNTER)) 
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(NZEROP  (REALLEQ  .COUNTER  21  ))@lnvariant 
(SO  (pro:) 

(mod:  MicroPC  COUNTER) 

(onv:  MicroPC) 

(post:  #COUNTER=(USSUI3  (TCPLUS  .COUNTER  1) 

31  OXSLobel))) 

(mod:  OMEGA) 

(onv.) 

(post:  //COUNTER=(REALPLUS  .COUNTER  1)einvariant 
(SO  (pre: ) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER=(USSUB  (TCPLUS  .COUNTER  1) 

31  O)0l.abol] 

([ApplySD  (SD  (pro:  ((USSUB  .SUM  31  31)=1 
and (USSUD  .GPXRB 31  31)=1 
or  (USSUB  .SUM  31  31)=0 
and  (USSUB  .GPXRB  31  31)=0) 

(NZEROP  (REALl.EQ  1  .COUNTER)) 

(NZEROP  (REALLEQ  .COUNTER  21  ))8lnvariant 
(SD  (pre:) 

(mod;  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER=(USSUB  (TCPLUS  .COUNTER  1) 
31  0)eLabel))) 

(mod:  OMEGA) 

(env:) 

(post:  (T  or  T) 

#COUNTER=(REALPLUS  .COUNTER  1  ^Invariant 


(SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER=(USSUB  (TCPLUS  .COUNTER 

1) 

31  0)@Labei] 


(Close))) 

(Portormlnduction  (SD  $) 


(SD  (&) 

$)) 

(ProposoModo  (SD  (pre:) 

(mod:  MicroPC  COUNTER) 

(env:  MicroPC) 

(post:  #COUNTER*(USSUB  (TCPLUS  .COUNTER  1) 
31  0)eLaboi))) 
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(InstantiatcContonts  W1  wl) 

[ProvobyCases 
[SD  (pre:) 

(mod:  OMEGA) 

(env:  OMEGA) 

(post:  (NZEROP  (REALEQUAL  (PRODUCT  (EXPVAL  #GPXRB) 

2) 

(EXPVAL  a))) 

[NZEROP  (REALLEQ  (POWER  (PRODUCT  (MANVAL  #GPXRB) 

(POWER  2  23)) 

2) 

(PRODUCT  (MANVAL  a) 

(POWER  2  56Q] 

( NZEROP  (REALLEQ  (PRODUCT  (MANVAL  a) 

(POWER  2  560)) 

(POWER  (REALPLUS  (PRODUCT  (MANVAL  #GPXRB) 
(POWER  2  20)) 

1) 

2] 

(((USEQL  (USSUB  .SUM  31  31) 

0) 

((ProposeMode))) 

((USEQL  (USSUB  .SUM  31  31) 

1) 

((ProposeMode] 

(ProposeMode]) 

(BATCHSQRT) 
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4.  CONCLUSIONS 


PLANNED  EXTENSIONS 

Tho  basic  theoretical  work  for  proofs  of  correctness  of  sequential  microcode  is 
reasonably  complete,  and  a  preliminary  system  for  carrying  out  proofs  has  been  built  and 
exorcised.  Within  the  scope  of  the  present  work,  the  following  extensions  are  planned. 

Proof  Language 

The  system  Is  divided  into  a  user  interface  and  a  rigorous  proofehecker.  In  the  present 
implementation,  the  user  Interface  knows  too  little  about  the  direction  of  the  proof.  In  a 
proof  by  cases,  for  example,  the  separate  coses  are  presented  to  the  proofehecker, 
then  combined.  It  is  possible  to  dectore  the  intended  result  in  a  superior  proof,  but  no 
use  is  made  of  this  information  in  either  the  user  interface  or  the  kernel. 

Wo  now  sno  that  thn  user  interface  can  interpret  a  simple  goal*oriented  language.  For  a 
proof  by  cases,  tho  user  would  specify  whot  lemma  Is  to  be  proven  and  would  specify 
that  tho  form  of  the  proof  is  to  be  by  cases  with  a  given  predicate.  Room  for  specifying 
tho  details  of  each  subproof  would  also  exist,  but  the  packaging  of  the  separate  proofs 
would  be  carried  out  by  the  proofehecker.  In  the  present  system,  a  proof  by  cases  now 
looks  like  the  following: 

(Open  P) 

(Open  P  and  C) 

<dctails  of  tho  proof  of  the  first  casa> 

(Close  P  and  C) 

(Open  P  and  not  C) 

<dctails  of  the  proof  of  the  second  case> 

(Close  P  and  not  C) 

(CombinoCoscs) 

(Close  P) 

In  many  Instances,  tho  proof  of  each  case  may  be  carried  out  automatically.  In  the 
present  system,  a  ProposeModo  statement  is  required.  We  can  eliminate  the  "obvious" 
proofs  if  we  uso  null  lists  where  proof  details  are  permitted.  Combined  with  the 
automatic  setup  and  packaging  of  compound  proofs,  the  proof  above  might  become  the 
following: 
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(Provo  P  (Cosos  C  (room  for  details  of  positive  subcase) 

(room  for  details  of  negative  subcase)) 

Similar  savings  would  result  in  proofs  by  induction.  Some  of  the  savings  are  not  apparent 
from  proof  sketches  like  the  ones  above.  The  lemmas  are  often  quite  lengthy.  Even  with 
the  lemma  suppressed  from  the  Close  command,  the  current  system  requires  three 
copies  of  the  main  lemma,  one  for  the  statement  of  the  lemma  in  the  main  proof,  and  two 
more  for  the  subcase  proofs.  The  compressed  form  requires  only  one  appearance  of  the 
lemma.  In  addition,  the  compressed  form  is  much  more  readable  and,  we  hope,  more 
writablo. 

Editing 

The  present  system  permits  only  limited  editing  of  the  proof.  Using  the  structured  proofs 
illustrated  above,  it  should  be  possible  to  edit  a  proof  quite  freely  and  have  the  proof 
restarted  from  the  last  point  it  was  changed. 

Efficiency 

The  present  system  is  fairly  slow.  With  a  little  experimentation,  it  has  become  clear  that 
a  lot  of  time  is  expended  In  the  simplifier.  The  simplifier  has  evolved  through  an 
accrotion  process,  and  is  due  for  a  comptete  redesign.  We  have  also  studied  Derek 
Oppen's  work  (see,  for  example,  [Nelson  and  Oppen  78]),  and  it  appears  reasonable  to 
uso  his  simplifier  for  parts  of  the  system.  His  simplifier  Is  carefully  crafted  and  should  be 
much  faster. 

FUTURE  CONSIDERATIONS 

A  number  of  Ideas  for  logical  next  steps  have  emerged,  though  these  are  beyond  the 
scopo  of  the  present  effort. 

Floating  Point  Arithmetic  Specification 

It  Is  obvious  that  wo  must  allow  other  floating  point  formats  than  that  of  the  FTSC.  The 
parameters  nooded  to  specify  the  format  should  be  variables  which  can  be  set  by  the 
user  to  fit  his  particular  application.  In  addition,  floating  point  arithmetic  needs  to  be 
characterized  precisely.  Notation  to  describe  the  intended  precision  of  the  results  and 
relationship  botween  floating  point  operations  and  the  corresponding  abstract  operations 


on  tho  reals  would  materially  reduce  the  size  of  the  target  machine  description  and 
remove  the  need  for  proving  a  separate  sot  of  constraints. 

Some  of  tho  initial  work  has  been  done  by  Brown  and  others  [Brown  77,  Brown 
78,  Wijngaardcn  64,  Kahan  77 a,  Kohan  77b]. 

Timing 

Performance  characteristics  play  a  large  part  in  the  design  of  host  machines  and  In  the 
design  of  tho  microcode.  However,  to  date  no  work  has  been  done  to  characterize  the 
running  timo  of  microcode.  Proofs  of  running  time  limits  should  be  reasonably 
straightforward,  but  work  is  needed  on  the  specifications. 

Concurrency 

Essentially  no  work  has  been  done  on  correctness  proofs  of  truly  concurrent  microcode. 
The  present  work  requires  a  sequentialized  model  of  the  host  and  target  machines. 
Extensions  to  the  basic  theory  will  be  required  to  model  concurrency. 
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Appendix  A 
THE  SYSTEM 

This  appendix  describes  the  operation  of  the  proofcheeker,  the  state  delta  expression 
language,  and  the  simplifier. 

A.1  PREPARING  AND  RUNNING  A  PROOF 

The  MICROVER  systom  is  a  LISP  program  that  is  loaded  from  TOPS20  exec  by  typing 
<AMDSYS>MICROVER.EXE2.  The  program  Is  started  by  the  LISP  function  StartExee,  and 
can  be  restarted  by  the  function  ContinueExec.  Both  functions  put  the  system  in  exec 
mode,  which  provides  a  set  of  commands  to  prepare  and  run  proofs. 

The  proof  checker  is  driven  by  a  sequence  of  proofsteps.  Each  proofstep  is  submitted 
one  at  a  time  to  the  kernel,  which  checks  its  applicability  and  updates  the  state  of  the 
proof  according  to  the  specific  proofstep.  Although  the  user  is  responsible  for  preparing 
the  proofsteps,  the  MICROVER  system  provides  various  aids  for  preparing  and  submitting 
thorn.  The  most  Important  aid  is  the  the  batch.  The  batch  consists  of  a  sequence  of 
proofsteps  that  is  submitted  by  MICROVER  under  user  supervision. 


A.1.1  Exec  Mode 

Exec  mode  provides  several  ways  to  prepare  and  submit  proofsteps,  as  well  as  some 

miscellaneous  tasks. 

The  following  commands  are  used  to  prepare  and  submit  proofs: 

UsorModc  This  command  puts  the  system  in  a  mode  that  provides  the  user 

with  convenient  facilities  to  prepare  individual  proofsteps.  In 
particular,  it  completes  key-words,  prompts  with  parameter  names, 
etc.  The  proofsteps  are  prepared  one  at  a  time,  and  submitted 
immediately. 

SaveTranscript  This  command  accumulates  the  successful  proofsteps  from  the  last 
session  into  a  batch.  The  batch  (in  the  form  of  a  LISP  function)  can 
be  stored  away,  submitted  agsin,  or  otherwise  manipulated. 
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The  system  is  currently  available  on  the  ISIE  machine,  accessible  over  the  ARPANET, 
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BatchModo  This  command  controls  the  submitting  of  a  batch.  See  below  for 

more  details. 

FixLost  Lets  the  user  edit  and  resubmit  the  proofstep  that  was  last 

submitted.  The  full  power  of  the  INTERLISP  editor  is  available.  It  is 
a  convenient  way  to  recover  from  an  error. 

GenBATCH  GenBATCH  prepares  a  batch  of  proofsteps  according  to  the  ISPS 

descriptions  of  the  target-machine,  host-machine,  ROM,  and 
mopping.  This  command  is  used  for  symbolic  simulation. 

Three  TOPS20  files  and  two  LISP  variables  must  exist  before 
executing  GenBATCH:  The  description  of  the  target,  host  and  ROM 
should  reside  in  the  files  TARG.ISP,  HOST.ISP  and  ROM.ISP, 
respectively.  The  mapping  should  reside  in  the  LISP  variables 
MAPPINGSLIST  and  COVERINGSLIST. 

The  result  of  GenBATCH  is  a  list  of  proofsteps  for  submission  In 
batch  mode.  The  user  is  queried  as  to  where  to  store  the  list. 

Tho  following  miscellaneous  commands  are  provided  by  exec  mode: 

RosotProof  Clears  the  whole  proof,  ready  to  begin  a  new  session. 

SctSwitch  Sets,  resets,  or  checks  the  value  of  a  trace  switch. 

DisploySWLIST  Displays  the  value  of  all  the  trace  switches. 

DisployStoto  Displays  the  current  state  of  the  proof. 

DisployLost  Displays  the  last  proofstop  that  was  submitted. 

Qu't  Returns  the  system  to  the  LISP  level. 

A. 1,2  BatchMode 

Batchmode  initializes  and  controls  the  submitting  of  a  batch  that  exists  as  a  TOPS20  file. 
This  batch  could  be  generated  off  line  using  an  editor,  by  the  SaveTranscript  command, 
or  by  the  GenBATCH  command  (see  next  section).  It  provides  the  following  batch 
commands: 

OponBatch  Reads  the  batch  from  a  file  and  initializes  the  batch-pointer  to  the 

first  proofstep  in  the  file. 
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DispiayNext 

■-1W  1 

Displays  the  proofstep  to  which  the  batch  pointer  is  pointing. 

PorformNoxt 

Submits  the  proofstep  to  which  the  batch-pointer  is  pointing  and 
advances3  it. 

Ooit 

Performs  a  fixed  number  of  proofsteps  from  the  batch  file.  The 
user  is  asked  for  the  number. 

WholeBatch 

Displays  the  complete  list  of  proofsteps  in  the  batch  file  last  read 
by  OpenBatch. 

Quit 

Returns  to  the  exec  mode. 

A.2  BASIC  PROOFSTEPS 

Tho  basic  "proof  action”  that  MICROVER  uses  is  setting  goal  to  sd:post,  and  advancing 
the  current  state  until  the  goal  becomes  true.  Using  combinations  of  this  proof  action  for 
the  right  state  deltas  can  accomplish  symbolic  execution,  symbolic  simulation,  proofs  by 
cases,  or  proofs  by  Induction. 

Mil  HOVER  provides  a  data  base  to  hold  the  current  state  and  a  kernel  that  processes  a 
sequence  of  basic  proofsteps.  Before  carrying  out  a  proofstep,  MICROVER  checks  that 
oH  of  the  requirements  are  satisfied.  If  they  are  not,  an  error  message  is  printed  and  the 
proofstep  Is  aborted  with  no  change  to  the  data  base.  The  following  basic  proofsteps 
are  available  In  the  system: 

A.2.1  Beginning  and  Ending  a  Proof 

(Open  vars-list  sd)  meaning:  Initiates  proof  of  sd. 

arguments:  sd  is  a  state  delta  and  vars-list  is  a  list  of  places  or 
variables. 

requirements:  The  places  In  sd:mod  and  sd:env  must  be  registered 
(see  below). 

effects:  Creates  a  current  state  consisting  of  sd:pre  and  those 

3 

in  cur  of  failure,  the  exec  command  DitplayLait  and  rixlait  Kill  peinta  to  tho  tailed  proofttep  (and  can  bo  uaod  for 
recovery) 
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predicates  from  the  previous  state  whose  support  is  contained  in 
sd:env;  creates  a  new  goal  of  sd:post;  the  prior  state  of  the 
database  and  the  place  graph  are  restored  when  the  proof  is 
complete,  except  that  the  proven  state  delta  is  added  to  the  prior 
state.  (See  Close,  below). 

(Close)  meaning:  Terminates  the  proof  of  the  most  recently  Opened  state 

delta  (goal)  assuming  the  postcondition  of  goal  is  true  in  the 
current  state. 

arguments:  none 

requirements:  sd:post  simplifies  to  true. 

effects:  Restores  the  proof  system  to  its  state  prior  to  the  most 
recent  Open,  with  the  addition  of  the  proven  state  delta. 


A.2.2  Registering  Places 

(NewDocomposition  covering) 

meaning:  Registers  new  subplaces. 

arguments:  Covering  is  of  the  form  (Covering  place  ((subplace 
length)  ...  (subplace  length))). 

requirements:  Mother  place  must  be  registered;  daughter  places 
must  not  be  registered. 

effects:  The  place  graph  la  extended  with  new  covering 

relationship. 

(NowComposition)  meaning:  Registers  new  superplaces. 

arguments:  Covering  as  above. 

requirements:  Mother  place  must  not  be  registered;  daughter 
places  must  be  registered  and  disjoint. 


effects:  The  place  graph  is  extended  with  new  covering 

relationship. 


A.2.3  Advancing  the  Computation 

(ApplySO  sd)  meaning:  Advance  the  execution  by  applying  sel. 

arguments:  sd  is  a  state  delta. 

requirements:  sd:pre  must  simplify  to  true  in  the  current  state,  and 
sd:mod  must  be  contained  in  the  modification  list  for  the  most 
recently  Opened  state  delta. 

effects:  Deletes  from  the  current  state  all  predicates  supported 
by  places  in  sd:mod,  and  adds  sd:post. 

A.2.4  Case  Analysis  and  Loops 
(CombineCases  sd-list) 

meaning:  Combines  the  state  deltas  in  sd-list  into  one  state  delta. 

arguments:  sd-iist  is  a  list  of  state  deltas  (sd^  ...  sdn)  where  sd( 
is  of  the  form 

(SD  (pre:  case.( 
pred) 

(mod:  MOD.) 

(env:  ENV.) 

(post:  POST.)), 

requirements:  All  sd(  must  be  true  in  the  current  state, 
effects:  Adds  the  following  state  delta  to  the  current  state: 

(SD  (pre:  (OR  ca9e^  . . .  easen) 
pred) 

(mod:  PIODj  U  . . .  U  M0Dn) 

(env:  ENVj  u  ...  U  ENVn> 

(post:  (OR  POSTj  ...  P0STn>) 

(Performlnductlon  loop-sd  base-sd) 

meaning:  Derives  a  state  delta  representing  the  state 

transformation  from  the  start  of  a  loop  to  its  termination  (the 
number  of  times  through  the  loop  being  known  in  advance). 

arguments;  base-sd  is  a  state  delta  representing  the  state 
transformation  for  the  first  time  through  the  loop,  and  loop-sd  Is  the 
state  delta  representing  the  state  transformation  once  through  the 
loop,  starting  after  on  arbitrary  number  of  iterations,  in  the 
following  from  and  (o  ora  numbers,  Indvar  is  a  bitstring  term,  claim 
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Is  what  Is  to  be  proved  (written  as  a  list  (or  conjunction)  of 
predicates  in  the  state  delta  expression  language),  and  program  Is 
a  state  delta  encoding  the  execution  of  the  loop. 

base-sd  must  be  of  the  form: 

(SO  (pre:) 

(mod: ) 

(env:  OMEGA) 

(post:  Indvar*  from 
claim  [from/  to) 
program ) 

loop-sd  must  be  of  the  form: 

(SD  (pre:  from  <  Indvar 
Indvar  <  fo 
claim 
program) 

(mod:  (no  restriction)) 

(env:  ) 

(post:  indvarUt/.)  -  Indvar  +  1 
claim  ill/. ) 
program) ) 

requirements:  base-sd  and  loop-sd  must  be  in  the  current  state. 

effects:  If  base-sd  and  loop-sd  are  in  the  current  state, 

Performlnduction  adds  the  following  state  delta  to  the  current 
state: 

(SD  (pre:  program) 

(mod:  loop-sd: mod) 

(env:  OMEGA) 

(post:  indvarltt/.)  -  fo 

clalmitt/.,  to/ Indvar) 
program) ) 


A.2.6  Mapping  Between  Levels 

(ApplyMapping)  meaning:  Searches  the  current  state  for  an  "applicable"  mapping 
and  "applies"  it. 

arguments:  none 

requirements:  There  must  be  an  applicable  mapping. 

effects;  Finds  a  mapping  with  mapplng:from  true  In  the  current 
state,  and  adds  mapplngsto  and  mapplng:map  to  the  current  state. 


A.2.6  Static  Reasoning 

(InstontlateContents  place  var) 

meaning:  Instantiates  the  contents  of  place  to  be  var. 

arguments:  Place  is  already  registered  and  var  Is  new;  both  are 
atoms. 

requirements:  Place  must  be  registered,  var  must  be  new,  and 
both  must  be  atoms. 

effects:  Substitutes  var  for  (.place)  everywhere  in  the  current 
state,  and  adds  the  predicate  (.place)-var. 

(Oerlve  exp)  meaning:  Inserts  exp  into  the  current  state. 

arguments:  Typically  exp  Is  a  predicate. 

requirements:  none 

effects:  Allows  direct  user  alteration  of  the  current  state;  thus 
would  not  be  used  in  a  completely  system-checked  proof. 

A. 3  HIGH  LEVEL  PROOFSTEPS 

Our  oxpcrienco  with  detailed  proofs  has  shown  that  there  are  patterns  of  proofstep 
soqucncos  that  can  be  lumped  together  to  a  single  (more  abstract)  proofstep.  High  level 
proofsteps  are  generally  only  necessary  for  setting  up  a  proof,  for  symbolic  execution  of 
straight  line  code,  for  execution  of  alternation,  for  execution  of  iteration,  and  for 
performing  symbolic  simulation. 

The  sot  of  high  level  proofsteps  forms  a  language  that  is  compact  and  structured.  Using 
this  language  makes  it  easier  to  read  or  write  proofs. 

(Prove  sd  proof)  meaning:  Proves  sd  by  proof. 

arguments:  sd  is  a  state  delta  and  proof  Is  a  list  of  proofsteps. 

requirements:  Those  of  Open. 

effects:  Performs  (Open  NIL  sd)  and  then  sequentially  processes 
the  elements  of  proof. 

(ProposeMode  breakpoint) 
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meaning:  Symbolically  executes  from  the  current  state  until 

breakpoint  is  reached  or  until  a  (Close)  can  be  performed. 

arguments:  breakpoint  is  a  predicate. 

requirements:  none 

effects:  Checks  to  see  if  Breakpoint  is  true  in  the  current  state;  if 
yes,  halts;  if  not,  checks  to  see  if  (Close)  is  possible;  if  yes, 
(Close)  is  performed;  if  not,  checks  to  see  if  there  is  an  applicable 
state  delta  sd;  If  yes,  performs  (ApplySD  sd);  if  not,  halts  with  the 
message  "Proofcheckor  has  nothing  to  propose". 

(ProvobyCoses  sd  case-proof-list) 

meaning:  Proves  (a  state  delta  equivalent  to)  sd,  by  using  the 
case  analysis  specified  in  case-proof-list. 

arguments:  sd  is  a  state  delta,  and  case-proof-list  is  a  list  of  the 
form 

Ucase^  proof^)  ...  (casen  proofn)) 

where  ti  cases  are  predicates  specifying  the  different  cases  and 
the  proofs  are  lists  of  proofsteps  which  prove  sd  in  case  casBj  is 


requirements:  Those  of  (CombineCases). 

effects:  Sequentially  treats  the  elements  of  case-proof-list  by 
adding  pred  to  sd:pre  and  then  sequentially  processing  proof. 
After  the  last  element  of  case-proof-list  is  processed, 
(CombineCases  (sd^  ...  sdn))  is  performed  where  sdj  is  sd  with 
case(  added  to  Its  precondition. 


(SymSimulate) 


meaning:  Proves  a  series  of  simulation  relationships, 
arguments:  none 
requirements:  none 

effects:  Assumes  that  the  goal  is  a  list  of  state  deltas  to  be 
proved  (sd  ...).  For  each  sd  in  the  goal  performs  the  following 
sequence  of  proofsteps:  (Open  NIL  sd),  (ApplyMapping), 

(ProposeMode  b),  (ApplyMapping),  (Close).  The  breakpoint  b  in 
ProposeMode  is  mapping-.from  of  the  mapping  for  which  mapping:to 
is  true  in  sdipost. 
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(InitProof  program)  meaning:  Initializes  the  system  in  order  to  prove  something  (to  be 
specified  in  a  later  (Prove)  proofstep)  about  program. 

arguments:  program. isp  is  a  file  containing  an  ISPS  program. 

requirements:  program  must  bo  a  valid  ISPS  program. 

effects:  Translates  program  Into  the  internal  state  delta 

representation,  and  initializes  the  placesystem  using  the 
information  on  the  declared  places  in  program. 

A.4  STATE  DELTA  EXPRESSION  LANGUAGE 

In  this  section  we  describe  the  function  symbols  used  in  the  state  delta  language.  This 
language  is  intended  to  accommodate  all  the  needs  of  the  whole  system,  from  translating 
a  machine-description  program  in  ISPS,  to  writing  down  the  high  level  specification,  to 
writing  down  the  proof.  Thus  we  deal  with  placenames  (program  identifiers),  bitstrings, 
arrays,  and  several  varieties  of  numbers. 

DATA  DOMAINS 

P  Places  (in  a  machine;  or  in  general  any  set  of  "names") 

B  Bitstrings 

N  Natural  Numbers 

Z  Integers 

Q  nationals 

A  Arrays  (considered  as  a  superset  of  B) 

{T.NIL}  Truth  values 

In  tho  following  wo  give  the  definitions  of  the  function  symbols.  The  constant  bitstrings 
oro  value-length  pairs  written  m(n)  where  m<2n.  Note  that  there  Is  only  one  legal 
bitstring  of  length  0,  that  of  value  0.  The  symbols  and  £  are  logical  equality,  and 

arithmetical  symbols.  Additional  "support  functions"  are  mod,  lnt(x)«lntegral  part  of  x, 


maxlh(a.b)  =  max{(LH  a),  (LH  b)},  and  tctous(i.n)  (2's  complement  to  unsigned),  which 
takos  1C Z  and  n<N  such  that  -2n’^J»i<2n”^  and  returns  that  non-negative  number  which  is 
tho  unsigned  value  of  the  bitstring  of  length  n  representing  i  in  2's  complement.  Thus, 
tctous(i,n)=if  i>0  then  i  else  2n*i.  So,  tctous(-3,4)=13,  tctous(-4,3)=4,  and  tctous(-3,2) 
Is  undefined.  Notice  that  in  all  the  uses  of  tetous  below,  the  arguments  satisfy  the 
conditions  for  the  definition.  "Expslf  p  then  x  else  y"  is  a  short  form  of  writing  a 
definition  of  Exp  by  cases:  If  p  is  true,  then  Expsx;  if  p  is  false,  then  Exp=y.  The  union 
of  two  sets  is  denoted  by  U;  thus,  for  example,  in  the  specification  of  LH,  LH:PUAUN~>N 
means  that  LH  Is  a  function  taking  either  a  place,  array  (and  hence  bitstring),  or  number, 
and  returning  a  number. 

(DOT  p)  .p  Contents  of  p 


'■•OTjP— >A 

DOT  is  an  arbitrary  function  subject  to  the  restrictions  that  (LH  p)=(LH  .p) 
ond  (HT  p)=(HT  .p). 


(LH  x)  Length  of  x 

LH:PUAUN— >N 

The  length  of  a  place  is  an  arbitrary  natural  number. 

Tho  length  of  an  array  is  the  same  as  the  length  of  all  its  rows. 

The  length  of  a  bitstring  b  is  a  natural  number  J  such  that  i<2^, 
where  i=(USVAL  b). 

Tho  length  of  a  natural  number  is  one  more  than  the  number  of  binary  digits  < 
needed  to  represent  it. 

(HT  x)  Height  of  x 

HT:PUAUN-->  N 

The  height  of  a  place  is  any  natural  number 
Tho  height  of  an  array  is  the  number  of  its  rows. 

Tho  height  of  a  bitstring  or  natural  number  is  1. 

(USVAL  b)  Unsigned  value  of  bitstring  b 

USVAL:B— >N 

The  case  by  case  definition  is  given  below. 

Note  that  Places  do  not  have  USVAL's;  however  Numbers, 
considered  as  bitstrings,  do. 
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Two's  complement  value  of  b 


(TCVAL  b) 

TCVAL:B— >Z 

(TCVAL  b)elf  (USVAL  b)<2(LH  b)_1  then  (USVAL  b)  else  (USVAL  b)-2(LH  b) 

(VarBS  I  J)  Bitstring  of  USVAL  I  (almost)  and  LH  J 

VarBS:NXN— >B 
(USVAL  (VarBS  I  J))*i  mod  2J 
(LH  (VarBS  I  J))*) 

(BSEQL  a  b)  Equality  between  bitstrlngs 

BSEQL:BXB— >8 

(BSEQL  a  b)=if  (USVAL  a)=(USVAL  b)  and  (LH  a)=(LH  b)  then  1(1)  else  0(1) 

(USCONC  o  b)  Concatenation  of  a  and  b 

USCONC:BXB — >B 

(USCONC  a  b)=(VarBS  [(USVAL  a)*2(LH  b)  ♦  (USVAL  b)]  (LH  a)+(LH  b)) 

(USSUB  a  m  n)  Substring  of  b  from  bit  m  down  to  n 

USSUB:BXNXN— >B 

(USSUB  a  m  n)»  if  m>(LH  a)  then  (USSUB  a  (LH  a)-1  n) 
elscif  m<n  then  0(0) 

olso  (VarBS  int(((USVAL  a)  mod  2m+1)*2'n)  m-n+1). 

(USSUB  a  m)  m-th  bit  of  a 

(USSUB  a  m)=(USSUB  a  m  m) 

(BITS  p  (PAIR  m  n))  Subplace  of  p  from  bit  m  down  to  n 

BITS:  PXNXN-- >P 

(DOT  (BITS  p  (PAIR  m  n))=(USSUB  (DOT  p)  m  n) 

(BITS  p  m)  Alternative  form  for  (BITS  p  (PAIR  m  m)) 

(DOT  (BITS  p  m)=(USSUB  (DOT  p)  in) 

(BITPLUS  a  b)  Same  length  bit  addition 

BITPLUS:BXB— >B 

(BITPLUS  a  b)»(VarBS  [(USVAL  aMUSVAL  b)  mod  2ma*lh(«-b)]  maxlh(a.b)) 
BITPLUS  (essentlolly)  zero-extends  e  and  b  to  be  the  same  length,  adds  them, 
and  drops  the  carry,  if  any. 

BITPLUS  con  be  used  to  uniformly  define  USPLUS  and  TCPLUS. 


(USPLUS  a  b) 


Unsigned  addition 


USPLUS  :BXB-->B 

(USPLUS  a  b)=(VarBS  (USVAL  a)+(USVAL  b)  maxlh(a,b)*1 ) 
or: 

(USPLUS  a  b)=(BITPLUS  (USCONC  (VarBS  0  maxlh(a,b)+1 -(LH  a))  a) 
(USCONC  (VarBS  O  maxlh(a,b)+1  -(LH  b))  b)) 

(TCPLUS  a  b)  Two's  complement  addition 

TCPLUS-.BXB— >B 

(TCPLUS  n  b)  is  that  bitstring  of  length  maxlh(a,b)+1  whose  TCVAL  is 
(TCVAL  nMTCVAL  b).  There  are  several  possible  ways  to  describe  that 
in  terms  of  VarBS. 

(TCPLUS  a  b)= 

(VorBS  tctous((TCVAL  a)*(TCVAL  b),maxlh(a,b)+1 )  maxlh(a,b)+1 )). 

Or  in  terms  of  BITPLUS: 

(TCPLUS  a  b)*(BITPLUS  (USCONC  0(1)  (SE  a  maxlh(a.b))) 

(USCONC  0(1)  (SE  b  maxlh(a.b)))), 
where  SE  Is  defined  below. 

(USDIFFERENCE  a  b)  Unsigned  difference 

USDII  TERENCE:BXB~>B 
(USOII  FERENCE  a  b)= 

(VarBS  tctous((USVAL  oMUSVAL  b),maxlh(e,b)+1 )  maxih(a.b)+1 ) 

(TCDIFFERENCE  a  b)  Two's  complement  difference 

TCDIFFERENCE:BXB->B 
(TCDIFFERENCE  a  b)= 

(VorBS  tctous((TCVAL  a)-(TCVAL  b),maxlh(a,b)«-1 )  maxlh(a,b)+1 ) 

(USTIMES  a  h)  Unsigned  multiplication 

USTIMES:BXB-->B 

(USTIMES  o  b)=(VarBS  (USVAL  a)*(USVAL  b)  (LH  a)+(LH  b)) 

(TCTIMES  a  b)  Two's  complement  multiplication 

TCTIMES:BXB->B 
(TCTIMES  a  b)= 

(VorBS  tctous((TCVAL  a)*(TCVAL  b),(LH  a)*(LH  b))  (LH  a)+(LH  b))) 


(USEOL  a  b) 


Unsigned  equality 


USEQL:BXB— >B 

(USEOL  o  b)*  if  (USVAL  a)*USVAL  b)  then  1(1)  else  0(1) 

(TCEQL  a  b)  Two's  complement  equality 

TCEQL:BXB— >B 

(TCEOL  a  b)*  if  (TCVAL  a)=(TCVAL  b)  then  1(1)  else  0(1) 

(USNEQ  o  b)  Unsigned  inequality 

USNEO:BXB->B 

(USNEQ  n  b)s  if  (USVAL  a)*(USVAL  b)  then  0(1)  else  1(1) 

and  similarly  for  the  other  bit  relations:  TCNEQ,  USLSS,  TCLSS,  USLEQ,  TCLEQ,  USGTR, 
TCGTR.  USGEQ,  TCGEQ 

(BITMINUS  n)  Same  length  two's  complement  negation 

BITMINUS:B— >B 

(BITMINUS  a)=(VarBS  (2(LH  a)-(USVAl.  a)  mod  2^LH  a))  (LH  a)) 

(USMINUS  a)  Unsigned  negation 

USMINUS-.B— >B 

(USMINUS  oMVarBS  tctous(-(USVAL  a),(LH  a)«-1)  (LH  a)+1) 

(TCMINUS  a)  Two's  complement  negation 

TCMINUS.B— >B 

(TCMINUS  a)=(VarBS  tctous(-(TCVAL  a),(LH  a)+1) (LH  a)+1) 

(SE  a  m)  Sign  extend  a  to  length  m 

SE:BXN— >B 

(SE  a  m)  has  the  sign  TCVAL  as  a  (if  mS(LH  a)).  Thus: 

(SE  a  m)=  if  m<(LH  a)  then  (USSUB  a  m-1  0) 
elso  (VarBS  tctous((TCVAL  a),m)  m). 

(USSLO  a  m)  Shift  left  m  bits  shifting  in  0 

USSL0:BXZ— >B 

(USSLO  a  m)*  if  m<0  then  (USSRO  a  -m) 

else  (USCONC  (USSUB  a  (LH  a)-1-m  0)  (USSUB  (VarBS  0  (LH  a))  m>1  0)). 

This  last  clause  can  also  be  written  as: 

(VarBS  (USVAL  a)*2mmod  2(LH  a)  m) 


(USSL1  a  m) 


Shift  left  m  bits  shifting  in  1 


USSL1  :BXZ-->B 

(USSL1  a  m)=  if  m<0  then  (USSR1  a  -m) 

else  (USCONC  (USSUB  a  (LH  a)-1-m  0) 

(USSUB  (VarBS  2(LH  a)-1  (LH  a))  m-1  0)) 

(USSLR  a  m)  Shift  left  rotate 

USSLR-.BXZ— >B 

(USSLR  a  m)=  if  m<0  then  (USSRR  a  -m)  else 

(USCONC  (USSUB  a  (LH  a)-m-1  0)  (USSUB  a  (LH  a)-m)) 

(USSLD  a  m)  Shift  left  duplicate  right  bit 

USSLD:BXZ— >B 

(USSLD  a  m)=  if  (USVAL  (USSUB  a  0  0))=1  then  (USSL1  a  m) 
else  (USSLO  a  m) 

(USSRO  a  m)  Shift  right  m  shifting  In  0 

USSRO:BXZ-->B 

(USSRO  n  m)=  if  m<0  then  (USSLO  a  -m) 

else  (USCONC  (USSUB  (VarBS  0  (LH  a))  m-1  0)  (USSUB  a  (LH  a)-1  m)) 

(USSR1  a  m)  Shift  right  m  shifting  in  1 

USSR  1  :BXZ— >B 

(USSR1  a  m)=  if  m<0  then  (USSL1  a  -m) 

else  (USCONC  (USSUB  (VarBS  2(LH  a)-1  (LH  a))  m-1  0) 

(USSUB  a  (LH  a)-1  m)) 

(USSRR  a  m)  Shift  right  rotate 

USSRR:BXZ— >B 

(USSRR  a  m)=  if  m<0  then  (USSLR  a  -m) 

else  (USCONC  (USSUB  a  (LH  a)-1  m)  (USSUB  a  m-1  0)) 

(USSRD  a  m)  Shift  right  duplicate  left  bit 

USSRD:BXZ— >B 

(USSRD  a  m)=if  (USVAL  (USSUB  a  (LH  a)-1  (LH  a)-1))«1  then  (USSR1  a  m) 
else  (USSRO  a  m) 

Note  that  all  of  the  results  of  the  shifts  have  length  (LH  a) 

(USNOT  a)  Bitstring-logical  NOT 
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USN0T:B— >B 


(U50R  a  b)  Bitstring-logical  OR 

USOR:BXB— >B 

Zero-ex  tends  to  maximum  length  and  ORs 

(USAND  a  b)  Bitstring-logical  AND 

(USEOV  a  b)  Bitstring-logical  equivalence 

(USXOR  a  b)  Bitstring-logical  exclusive  OR 

Similarly 

(EXPVAL  a)  TCVAL  of  right  8  bits 

EXPVAL:B— >Z 

(EXPVAL  aMTCVAL  (USSUB  a  7  0)) 

(MANVAL  a)  Fractional  value  of  left  24  bits 

MANVAL:B~>Q 

(MANVAL  a)=(TCVAL  (USSUB  a  31  8))*  2'23 

(FLVAL  a)  Value  of  a  as  a  floating  number 

FLVAL:B— >Q 

(FLVAL  a)=(MANVAL  a)«2(E*PVAl  a) 

(NZEROP  a)  Not  zero  predicate 

NZER0P:B— >{T,NIL) 

(NZEROP  a)«  if  (USVAL  a)*0  then  NIL  else  T 

(POWER  q  I)  Integer  exponentiation  of  rationals 

P0WER:QXZ— >Q 

(REALMINUS  q)  Unary  arithmetic  negation 

REALMINUS:Q— >Q 

(PRODUCT  q  r)  Multiplication 

(REALPLUS  q  r)  Addition 

(REALDIFFERCNCE  q  r)  Subtraction 

(REALQUOTIENT  q  r)  Division 

All  these  from  QXQ— >Q 
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(REALEGUAL  q  r)  (Provable)  equality  between  arithmetic  terms 

REALEQUAL:QXQ->B 

(REALEGUAL  q  r)sjf  qsr  then  1(1)  else  0(1) 

(REAU.FQ  q  r)  (Provable)  less  than  or  equality 

REALLEQ:QXO— >B 

(REALLEG  q  r)=  If  q<r  then  1(1)  else  0(1) 

Now  we  describe  the  terms  dealing  with  arrays.  Two  arrays  are  the  same  iff  they  have 
the  same  height  and  the  same  sequence  of  words.  Thus:  We  have  no  function  analogous 
to  USVAL  for  arrays,  although  it  is  an  easy  matter  to  uniquely  assign  a  number  to  an  array 
on  the  basis  of  tho  USVALs  of  its  words.  We  number  the  rows  of  an  array  from  top  to 
bottom,  starting  with  0.  We  have  learned  to  view  as  natural  the  apparent  discrepancy 
between  the  top-down  ordering  of  rows  in  an  array  and  the  right-left  ordering  of  bits  in  a 
bitstring. 

(WORDS  a  m  n)  The  rows  of  a  from  m  down  to  n 

WORDS:AXNXN— >A 

(HT  (WORDS  a  m  n))=if  ni(HT  a)  then  (HT  (WORDS  a  m  (HT  a)-1» 
elseif  m>n  then  0 
else  n-m*1 

(WORDS  a  m)  m-th  word  of  a 

(WORDS  a  n)*.  WORDS  a  n  n) 

(SUBARRAY  a  i  j)  The  columns  of  a  from  i  to  J 

SUBARRAY:  AXNXN—>A 
(HT  (SUBARRAY  a  I  J))=(HT  a) 

(WORDS  (SUBARRAY  a  i  j)  m  m)*(US5UB  (WORDS  a  m  m)  i  J) 

(RANGE  a)  The  concatenation  of  the  rows  of  a 
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RANGE:A~>B 

(RANGE  a)=(USCONC  (WORDS  a  0  0)...(WORDS  a  (HT  a)-1  (HT  a)-D) 

It  is  convenient  to  define  (RANGE  x  y)  for  two  bits  of  the  explicit  form 
x=(USSUB  (WORDS  a  jx  jx)  ix  ix)  and  y=(USSUB  (WORDS  a  Jy  Jy)  iy  ly) 
or  in  the  degenerate  case  where  a  is  of  length  1, 
x*(WORDS  a  Jx  Jx)  and  y*(WORDS  a  jy  jy).  Its  value  is  the  word 
consisting  of  all  bits  from  x  to  and  including  y  inside  a. 

(ARRAYNGE  h  b)  Forms  b  into  an  array  of  height  h  . 

ARRAYNGE:NXB— >A 

Defined  only  for  b  such  that  hj(LH  b) 

(HT  (ARRAYNGE  h  b))=h 

(WORDS  (ARRAYNGE  h  b)  i  i)=  if  i<h  then 

(USSUB  b  (LH  b)-1-i*(LH  b)/h  ) 
else  0(0) 

(ARRAYCONC  li  a  b)  Forms  a  and  b  into  an  array  of  height  h 

ARRAYCONC-.NXAXA— >A 

Defined  only  for  h,a,b  such  that  li  divides  the  areas  of  a  and  b. 

(HT  (ARRAYCONC  h  a  b))*h 
(WORDS  (ARRAYCONC  h  a  b)  i  i)»  if  i<h  then 
(USCONC  (WORDS  (ARRAYNGE  h  (RANGE  (USSUB  (WORDS  a  0  0)  (LH  a)-1) 
(USSUB  (WORDS  a  (HT  a)-1  (HT  a)-1)  0  0)))  i  i) 

(WORDS  (ARRAYNGE  h  (RANGE  (USSUB  (WORDS  b  0  0)  (LH  b)-1) 
(USSUB  (WORDS  b  (HT  b)-1  (HT  b)-1)  0  0)))  i  i)) 
else  0(0) 


A.S  THE  SIMPLIFIER 

SIMPLIFIER  STRUCTURE 

In  this  section  we  describe  the  structure  of  the  simplifier  and  give  a  brief  description  of 
tho  purpose  of  each  of  its  files.  Entry  to  the  simplifier  is  through  the  function  SIMPEVAL. 
S/MPCVAUX)  returns  a  term  equivalent  to  X  If  X  is  a  term  (legal  expression)  In  the 
simplifier's  language.  The  simplification  i3  processed  recursively;  that  is,  if  X  is  not 
atomic,  then  the  arguments  of  X  are  first  passed  to  SIMPEVAL,  and  likewise  for  their 
arguments.  If  no  simplifeation  or  evaluation  is  possible  (by  the  system)  then  the  original 
argument  is  returned. 


73 


SIMPLIFY 


SIMPLIFY  consists  of  two  levels.  At  the  top  level,  the  function  SIMPEVAL  is  the  entry 
point  to  the  simplifier.  An  expression  to  be  simplified  is  sent  to  the  appropriate  second 
level  routine  by  SIMPEVAL  after  its  arguments  have  been  recursively  simplified  by  the 
same  process.  This  appropriate  routine  is  chosen  on  a  one-to-one  basis  depending  on 
the  principal  function  symbol  of  the  expression. 

The  second  level  routines  consist  of  three  parts:  if  the  simplified  arguments  are  not 
symbolic,  the  expression  is  evaluated  and  the  value  returned;4  If  not,  then  the 
expression  is  passed  to  one  of  the  files  listed  below  for  further  processing;  if  this  does 
not  result  in  further  simplification,  the  original  expression  with  simplified  arguments  is 
roturned. 

If  the  expression  is  of  type  real  numbers  or  integers,  or  relations  on  them,  and  the 
simplified  arguments  are  constant  numbers,  then  the  evaluation  is  done  by  LISP 
functions.  If  the  arguments  are  symbolic,  then  the  computation  calls  a  routine  In 
REALSIMP. 

If  tlio  expression  Is  of  type  bitstring  and  the  arguments  are  constant  bitstrings,  then  the 
evaluation  is  dono  by  functions  in  MOTE.  If  the  arguments  are  symbolic  then  the 
computation  calls  a  routine  in  ISPSSIMP. 

If  the  expression  is  of  type  value  of  bitstring,  and  the  arguments  are  constant  bitstrings, 
then  the  evaluation  is  done  In  SIMPLIFY  by  LISP  functions  and  perhaps  other  second 
level  functions.  If  the  arguments  are  symbolic,  the  computation  calls  a  routine  in 
VALUESIMP. 

If  the  expression  is  of  type  arrays  then  ARRAYSIMP  is  called. 

If  the  expression  Is  of  type  propositional  calculus,  and  the  arguments  are  not  logical 
constants  (T  or  NIL),  then  LOGSIMP  is  called. 


^Tht*  convention  is  not  strictly  observed:  some  function.-,  at  this  level  do  simplification  on  symbolic  expressions  and/or 
examine  the  data  base. 
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Each  of  these  flies  may  call  SIMPLIFY,  each  other,  or  OTHERBITSIMP  and  AUXILIARYSIMP. 
In  addition,  they  all  search  the  data  base  for  current  facts  which  may  Imply  some 
simplification  that  is  not  generally  true. 

REALSIMP 

This  file  contains  the  main  routines  for  simplification  of  algebraic  expressions  over  the 
domain  of  the  real  numbers.  The  relations  and  functions  recognized,  along  with  their 
internal  syntax,  are  addition  (REALPLUS),  subtraction  (REALDIFFERENCE),  multiplication 
(PRODUCT),  division  (REALQUOTIENT),  exponentiation  (POWER),  unary  negation 
(REALMINUS),  oquality  (REALEQUAL),  strict  order  (REALLESS),  and  weak  order  (REALLEQ). 

In  addition,  the  maximum  and/or  minimum  bound  on  a  real  variable  is  found  where  possible 
by  searching  the  data  base  for  the  entries  of  the  form  (REALLEQ  var  n)  or  (REALLEQ  n 
var)  where  n  is  a  numerical  constant.  The  Internal  syntax  for  these  minimum  and 
maximum  values  is  REALMIN  and  REALMAX. 

ISPSSIMP 

ISPSSIMP  is  the  file  simplifying  bitstring  expressions  (more  or  less  those  of  ISPS).  An 
important  point  Is  that  we  allow  bitstring  variables  to  have  variable  lengths  (including 
zero)  as  well  as  variable  contents.  A  constructor  expression  (formed  of  concatenation, 
substring  selection,  and  shifts)  is  reduced  to  a  standard  form  as  a  concatenation  of 
substrings,  where  two  adjacent  substrings  may  not  be  combined  any  further.  This 
standard  expression  is  almost  canonical;  that  is,  two  equivalent  bitstrings  reduce  to  the 
same  standard  expression  except  in  certain  cases  involving  registers  whose  variable 
length  may  include  zero. 

Two's  complement  or  unsigned  plus  and  difference  are  replaced  by  an  equivalent 
addition  or  subtraction  between  two  bitstrings  of  equal  length  and  sent  to  OTHERBITSIMP 
for  processing.  In  the  cose  of  bitstring  multiplication,  some  simplification  is  accomplished 
If  one  of  the  arguments  is  a  bitstring  with  known  value. 

If  the  expression  is  on  equality  between  bitstrings,  then  simplification  Is  accomplished  In 
many  cases,  either  completely  (i.e.,  to  the  bitstrings  1  or  0  representing  T  and  F)  or 
partially.  There  Is  also  some  use  made  of  REALSIMP  and  VALUESIMP,  for  example,  In  the 


eguivnlcnco  between  unsigned  equality  of  bitstrings  and  real  equality  between  their 
unsigned  values. 

OTHERBITSIMP 

OTHERBITSIMP  contains  routines  for  use  in  simplifying  bitstring  expressions,  and  is  in 
principle  subordinate  to  ISPSSIMP.  Included  are  routines  for  simplifying  the  non-carry 
bitstring  addition  BITPLUS,  sign-extension,  substrings  of  concatenations,  squashing 
together  two  adjacent  substrings  in  a  concatenation,  and  replacing  a  substring  of  the 
form  A<lh(o)-1:0>  by  A. 

VALUESIMP 

The  two  main  expressions  simplified  in  VALUESIMP  are  USVAL(A)  and  TCVAL(A),  the 
unsigned  and  two's  complement  value  of  the  bitstring  A.  In  addition  FLVAL(A),  EXPVAL(A), 
and  MANVAL(A)  are  expressions  representing  the  value  of  A  as  a  floating  number  (of 
customized  24-bit  mantissa  and  8-bit  exponent),  the  two's  complement  value  of  the 
exponent  of  A,  and  the  two's  complement  value  of  the  mantissa  of  A,  respectively. 

Typical  steps  in  a  recursive  simplification  are  changing  a  TCVAL  into  a  USVAL  where 
possible  (and  sending  the  result  back  to  SIMPEVAL),  changing  TCVAL(A)  Into  TCVAL(B) 
where  B  Is  simplor  than  A,  returning  an  Integer  instead  of  TCVAL  or  USVAL,  or  "pushing 
TCVAL  in"  and  roturlng  an  expression  of  the  form  TCVAL(A)*TCVAL(B). 

ARRAYSIMP 

ARRAYSIMP  simplifies  expressions  in  the  array  language  described  in  Mlcrover  Note  #12. 
This  language  allows  all  possible  row  and  column  and  subarray  selection,  reshaping,  and 
concatenation  of  two  rectangular  arrays  of  constant  height  and  length.  It  Is  completely 
integrated  with  the  bitstring  language  in  that  a  word  in  an  array  is  a  bitstring,  an  array  of 
height  1  is  a  word,  and  the  length  of  an  array  is  the  (common)  length  of  its  words.  The 
height  and  area  of  arrays  are  calculated  here,  but  the  length  is  calculated  in 
AUXIL1ARYSIMP. 

LOGSIMP 

LOGSIMP  rocognizes  formulas  of  the  propositjonal  calculus  written  with  Implication  and 
disjunction.  Free  individual  variables  are  allowed,  and  in  this  case  we  treat  the  formula 
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as  if  nil  tho  free  variables  were  universally  quantified. 

AUXILIARYSIMP 

This  file  contains  the  simplifications  of  the  other  "service"  functions  used  In  the 
simplifier.  First,  we  have  the  representation  of  an  arbitrary  continuous  piecewise  linear 
function  on  bounded  domain: 

(SLANT  v  (a  It)  (I.  s.)  (L  s,)  ...  (I  s  )). 

1  1  i  c  n  n 

whore  v  is  tho  function's  argument  variable,  a  is  the  left  endpoint,  h  Is  the  height  of  the 
graph  at  a,  and  from  thon  on  the  graph  continues  Ij  units  to  the  right  with  slope  Sj,  and 

then  I,  units  with  slope  s2,  etc.  There  are  routines  for  adding  slant  functions,  finding 

maximum  or  minimum  of  two  slants,  converting  from  standard  arithmetic  notation  to  slant 
notation,  etc.  Slants  are  used  mostly  as  lengths  of  variable  length  bitstrlngs. 

There  are  routines  for  calculating  the  length  of  bitstring  expressions,  inserting  and 
extracting  parentheses,  "multiplying  out"  arithmetic  expressions,  solving  linear 
equations,  and  converting  from  ratlonals  to  bitstrings  representing  them  In  floating  point 
format. 

PRINCIPLES 

In  tho  following  we  describe  the  principles  behind  some  simplifications  for  expressions  in 
tho  state  delta  language.  This  is  not  intended  to  be  a  complete  survey  of  all  possible 
simplifications,  but  rather  a  representative  list  of  those  simplifications  found  useful  In  the 
actual  practice  of  verification,  especially  the  square  root  algorithm  of  the  FTSC.  Thus 
there  is  a  close  correspondence  between  these  simplifications  and  those  actually 
Implemented  in  the  system.  Here,  though,  we  describe  only  the  "interesting"  ones,  and 
some  of  these  may  be  stated  in  different  form  without  mentioning  ail  the  cases  and 
specifying  the  implementation  details. 

BSC  (bitstring  constructor)  terms 

Tho  primitive  operations  for  constructing  bitstrings  are  concatenation  a@b,  substring 
selector  a<l:j>,  and  shifts.  The  definitions  of  concatenation  and  shifts  are  standard.  Our 
conventions  for  substring  selector  are  thnt  bitstrings  are  numbered  from  the  right-most 
bit  a<0>  to  tho  left-most  a<lh(a)-1>  where  lh(a)  Is  the  length  of  a.  Note  that  we  shall 


allow  bitstrings  to  have  variable  length.  These  are  called  generalized  bitstrings.  For 
Integer  i,  J  a<i:j>  represents  the  string  consisting  of  bits  I  down  to  j  of  a,  that  Is, 
a<i>ea<i»1>...@a<j>.  If  J  is  greater  than  i,  then  this  string  is  nonexistent,  and  is  called 
EMPTY.  If  i<0  or  i>lh(a)  then  a<i>  is  EMPTY.  In  the  following  f(i)  and  g(i)  will  be  functions 
attaining  integer  values  at  integer  values  of  the  argument  i.  We  will  occasionally  omit 
mention  of  i  and  write  just  f,  g. 

A  (generalized)  substring  is  a  term  of  the  form  a<f:g>  where  a  is  atomic. 

A  simplified  substring  is  the  EMPTY  string  or  is  a  substring  of  the  form  a<f:g>  where 
VI  f(l)  <  lh(a),  Vi  g(i)  i  0,  -Vi  f(i)  <  g(i). 

Note  that  when  f  and  g  are  constants,  these  conditions  become  f<lh(a),  g>0,  f£g.  Note 
also  that  we  cannot  demand  Vi  f(i)>g(i),  since  for  example  a<0:-i>  is  either  EMPTY  or 
a<0>  depending  on  i.  From  our  definition  of  the  semantics  of  substring,  it  follows  that 
any  substring  is  equivalent  to  a  simplified  substring:  a<f:g>=  a<min{f,  lh(a)-1}, 
max{g,0}>  or  EMPTY.  If  a  canonical  simplified  substring  is  desired,  some  standard  values 
of  f  and  g  will  have  to  be  taken  in  the  case  that  f(i)<g(i),  for  example  f(i)=0  and  g(i)=1. 

Longth  is  defined  for  a  (generalized)  substring  as  the  following  function  of  i:  (Let  a,  f, 
and  g  bo  functions  of  i) 

lh(a<ftg>)  (i)  ■  if  f ( i ) 2  lh(a(i))  then  lh(a< lh(a) -It g> (i ) ) 
elseif  g( i )  <  0  then  I h  (a<f I0>  ( I ) ) 
el  seif  Mi)<g(i)  then  0 
else  f ( i ) -g ( i ) +1 . 

An  oquivalont  closod  form  is 

lh(a<f:g>)  «  min{lh(a),  max(min{f,  Ih(a)-I)  -  max{g,  0}  ♦  1,  0}} 

This  allows  the  following  rewriting:  Let  0(1)  denote  a  string  of  f  zeroes. 

If  a  is  of  the  form  0(f)<g:h>,  then  a  =*  0(lh(a)).  ^ 

A  BSC  (bitstring  constructor)  term  is  any  term  formed  from  atomic  bitstrings, 
concatonotion,  substring,  and  shifts. 
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A  simplified  DSC  term  is  of  the  form  b  6b,6...6bn  where  nil  and  each  b.  is  a  simplified 
substring. 

It  can  bn  shown  that  every  BSC  term  is  equivalent  to  a  simplified  BSC  term.  The  main 
simplification  rules  used  in  simplifying  a  BSC  term  are 

(a6b)<f :ci>  =>  a<f-lh(b):  g-lh(b)>  0  b<f:g>  <2> 

a  SLO  f  O(min{lh(o),-f})0a<lh(o)-f-1:max{-f,O)>@O(min{lh(a),f})  (3) 

a<f1:gi><f2:g,>  =>  a<min{f1,f2-t-g1};max{g1,g1+g2}>  (4> 

Example  Assume  lh(a)=4,  lh(b)=5,  lh(c)sG. 

(a0(b0c)  SLO  5X1 3:3X6: 1>  => 

(O(-5)0(o0(b0c))<9:O>@O(5))<9:4>  => 

(CMPTY0(o<-2:-1 1  >@(b@c)<9:0>)@0(5))<9:4>  => 

(b<3:O>0c<9:O>0O(5))<9:4>  =* 
fb<3:O>0c0O(5))<9:4>  =p 

C<4:O>0O(  1 ) 

BSA  (bitstring  arithmetic)  terms 

All  tho  bitstring  addition  operators  are  translated  into  BITPLUS;  BITPLUS  is  noncarry 
addition  between  two  bitstrings  of  equal  length.  When  the  sign  *  appears  between 
bitstrings  it  will  always  denote  BITPLUS.  We  also  use  ♦  for  numerical  addition,  but  it  is 
clear  from  the  cot.  ,xt  which  is  intended.  USVAL(a)  is  the  nonnegative  integer 
represented  in  binary  by  the  bitstring  e. 

If  b  ond  c  ore  constant  bitstrings  and  USVAL(b)+USVAl(c)  <  then 

(aGb)*c  =*  a0(b+c)<lh(b)-1 :0> 

A  similar  simplification  rule  holds  for  c+(a@b).  Of  course  the  two  sides  of  5  are 
equivalent  even  If  b  and  c  are  not  constants,  but  then  the  right  side  Is  not  necessarily 
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simpler. 


BSR  (bitstring  relational)  terms 

There  are  two  main  classes  of  bitstring  relations:  unsigned  value  and  two's  complement. 
Every  unsigned  bitstring  relation  is  equivalent  to  the  the  corresponding  real  relation  on 
the  USVAL's  of  its  arguments.  For  example,  USEQL(a,b)  is  equivalent  to 
USVAL(a)=USVAL(b).  Similarly  for  two's  complement.  The  simplification  of  this  type  of 
relation  will  be  given  in  this  section.  The  section  on  real  relations  will  include  (among 
others)  "mixed  relations",  l.e.,  those  containing  both  USVAL  and  TCVAL.  TCVAL(a)  Is  the 
(signed)  integer  which  is  the  two's  complement  interpretation  of  the  bitstring  a. 

Equality 

Wo  let  a  =jjg  b  denote  USEQL(a,b)=T  and  similarly  for  TCEQL.  We  write  *  with  no 
subscript  if  identity  between  bitstrings  is  intended. 

If  Vij  (fl(i)<j<f2(i)  v  f2(i)<j<f1(i)  — >a<j>*0),  then 

a<,l:g>  =us  a<f2:g>  (6) 

If  =us  a,  and  bj  =us  b2  and  lh(bj)slh(b2),or  if  bj  =us  b2<lh(bJ)-1 :0>  and  ax  Sus 
a,0b  <lh(b,)-V.lh(b,)>,  then 

at0bt  aUS  a2@b2  (7) 


tf  a  =gS  O  and  b  *yg  0,  then 

aGb  =yg  0  (®) 

Of  course,  thero  aro  the  obvious  generatteations  when  an  arbitrary  constant  is  In  place  of 

0. 


,f  °1  Sus  °2  ond  bi  =us  b2  or  ai  *US  b2  and  bJ  "us  a2’  then 

a  *b  =, a  +b 
i  l  US  u2  2 

If  USVAL(o)i2,b(a)-2f  or  0>TCVAL(a)>-2f- V,  then 
a<f>  *  1 

If  a<fJ:gJ>  «us  0  for  some  fjif,  g^g,  then 


(9) 


(10) 
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(11) 


a<f:g>  Sus  0 

lf  a  *us  b  ond  a<l,1(a)-1>  =  b<lh(b)-1  >  (or  lh(a)slh(b)),  then 

asTCb  (12) 


if  c<f>  =  a<f+1  >  =  ...  s  a<lh(a)-1  >,  then 
a<f:0>  =TC  a 


(13) 


If  a<f*1>=n<f>=n<f-1>  ond  b<f*1>»b<f>=b<f-1>,  then 
(a  ♦  b)<f>  =  (a  ♦  b)<f+1  > 


(14) 


l(  tr «<Vso/>  Sus  b<V-<>*  V"fi  B  V'f2-  V*»l'  * 

or  if  a<lh(o)-1:gl>  =us  b<lh(b)-1  ;g2>,  a<f1*1>«...»a<lh(a)-1>*0,  b<f2+1>*...sb<lh(b)-1>=0, 
then 

a<fi!0»>  *US  b<W  (15) 


Ordering 

0<Tco  (16) 

if  and  only  if  n<lh(a)-1  >=0. 

BSV  (bitstring  value)  terms 

If  a<lh(a)-1  >=0.  then 

TCVAL(a)  =>  USVAL(a)  (17) 

If  a<lh(o)-1  >=0.  then 

USVAL(o)  =»  USVAl<a<lh(a)-2  0>)  (18) 

TCVAL(aGb)  =>  2,h(b)*TCVAl(a)  ♦  USVAL(b)  (19) 

USVAL(aGb)  *  2lh(b)*USVAL(a)  ♦  USVAL(b)  (20) 

If  lh(a)=lh(b),  a<f-l >eb<f-1  >«0,  a<f>»a<f«-1>»...»a<lh(a)-1>,  b<f>«b<f+1  >»...»b<lh(b)-1  >, 
then 

TCVAL((a*b)<f:0»  *  TCVAL(a*b)  (21 ) 

If  lh(a)»lh(b)  and  TCVAL(a)  ♦  TCVAL(b)  i  2lh(a)-1,  then 

TCVAL(a*b)  =>  TCVAL(a)+TCVAL(b)-2lh(o)  (22) 
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If  llt(o)-lh(b)  and  TCVAL(a)  ♦  TCVAL(b)  <  .2lWa)-1t  then 

TCVAL(a+b)  =>  TCVAL(a)  ♦  TCVAL(b)  ♦  2lh(a)  <23> 

If  lh(o)=lh(b)  and  -2lh(a)"1  STCVAL(a)  *  TCVAL(b)  <2lh(a)'1,  then 

TCVAL(a*b)  =>  TCVAL(a)  ♦  TCVAL(b).  <24) 

RA  (real  arithmetic)  terms 

We  list  here  only  the  rules  concerning  RA  terms  which  contain  BSV  terms. 

Let  ct  and  c2  be  functions  of  i  (as  are  the  f's  and  g's).  If  Cj,c2>0,  f^fj,  ant* 

VifCjdWCjO)  =>  g2(i)>f2(i)),  then 

c1*v(a<fl:g1>)  -  C2*v(a<f2:g2>)  =s  *25) 

c^«2niax(f2"92+1»0)«v(a<f1:g1+max(f2-g2+1,0)». 

Note  that  we  do  not  demand  that  Vi(f2>g2). 

If  a<lh(a)-1  >  =  1,  then 

TCVAL(a)  ♦  2lh(a)  d  USVAL(a).  (26) 

RR  (real  relational)  terms 

TCVAL(a<lh(a)-1  :n»  S  2“"»TCVAL(a)  <27) 
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Appendix  B 
FTSC  HOST 


FTSC  HOST 


!  FTSC . M I CROflACH I NE 


IThis  version  (Mar. 24,  1978)  has  made  it  through  elftst  618-S9A(1B). 
MICROFTSC: » ( 
ftrtfla  i  n.  Memory** 

MEM [0:32k]  <31 :0> ! ACTUALLY  MEM  IS  40  BITS  U1DE  BUT  HERE 
!UE  JUST  DEAL  UITH  THE  PART  THAT  FITS 
IONTO  THE  CPU  DATA  BUS. 

**R0M** 

! FTSC. CON TROM  P214-21G 


CONTROM1  [0:1 023] <31: 0>, 'THREE  SLICES  OF  CONTROM 
CONTROM2  [0:1023] <31 :0>, 

C0NTR0M3 [0: 1023] <13: 0>, 

mCUOROi<31:0>, 

niCUORG2<31:0>. 

MICUORD3<13:0>, 

RF01<4:0>,  !f1ICU0R01<31:27>, 

RF02<9:0>.  miCU0RDl<26:17>, 

RF03<2: 0>,  !  M I CU0RD1 <1G : 14>, 

RF0A<2: 0>,  !  M I CU0RD1 <13: 11>, 

RF05<2:0>,  !MICUORO1<10:8>, 

RF06<2:0>,  !niCU0RDl<7:5>, 

RF07<0>,  !niCU0R01<4>, 

RF0S<0>,  miCU0RDl<3>. 

RF03<2:0>,  !MJCUORO1<2:0>, 

RF10<2:0>.  !MICU0R02<31:29>, 

RF1 1 <0>,  !MICUORD2<28>  , 

RF12<0>,  !MICU0RD2<27>  , 

RF1 3<0>.  !f11CU0RD2<26>  , 

RF14<0>,  !f1ICU0R02<25>  , 

RF15<2:0>,  !MICU0R02<24:22>  , 

RF1G<2:0>,  !MICU0RD2<21:19>  , 

RF17<3:0>,  !MICU0R02<18:1S>  , 

RF1S<3:0>,  !MICU0R02<14:11>  , 

RF19<0>,  !MICUORD2<10>  , 

RF20<0>,  !M1CU0RD2<9>  . 
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VMM 


mm/mm 


RF2l<0>, 

RF22<2:0>, 

RF23<8>, 

RF24<0>, 

RF25<0>. 

RF26<0>. 

RF27<0>. 

RF2S<0>. 

RF29«0>, 

RF30<0>, 

RF31<4:0>, 

RF32<0>. 

RF33<0>, 

RF34<0>, 

RF35<0>. 

RF3G<0>, 

RF37<0>, 


!MICW0RD2<8>  , 
!MICU0RD2<7:5>  , 
!MICW0RD2<4>  , 
!HICU0RD2<3>  , 
!mcuono2<2>  , 

!M1CU0RD2<1>  , 
!M!CWORD2<0>  , 
!M1CU0RD3<13>, 
*mCU0RD3<12>, 
miCU0RD3<U>, 
!MICUORQ3<10:6>, 
•mCU0RD3<5>, 
!M1CU0RD3<4>, 
!(1ICU0RD3<3>, 
!MICU0RD3<2>, 
!MICW0RD3<1>, 
!M1CUORO3<0>, 


IFTSC. ROMSEQUENCER  P213.217 


RECONFIGROM  [0: 10231  <31:0>, ! RECONFIGURATION  ROM  P121 
•RECONFIGROM: =MEM  ["F7FF; "F000I  PG3 
RAD<9:0>, INEXT  ROM  ADDRESS 
ROMA4-c0>:-RF02<5>, 

ROMA5<0>: -RF02<4>, 

ROMA6<0>: -RF02<3>, 

ROMA7<0>: -RF02<2>, 

ROMAS<0>;-RF02<1>, 

ROMA9<0> : -RF02<0> , 


AMODE<0>,!-0  IFF  ADDRESS  MODE-0 

HONMD<0>.!-1  IN  MONITOR  CPU 

CNTRL<0>. !-l  IF  CONTROL  PANEL  WANTS  ACCES  TO  CPU 

SUMM1<0>, ! "SUM<32>" . THE  INPUTS  TO  THE  ALU 

!ARE  SIGN-EXTENDED  TO  40  BITS  AND  THEN  A  DIFFERENCE  BETWEEN 

ISUMM1  AND  SUM<31>  INDICATES  OVERFLOW  (OVFF). 

SUMM2<0>, !"SUM<33>" 

! F  TSC . ROMFUNC T I ONOECODER  P.220 


RFD00<0>, 

RFDO1<0>. 

RFD02<0>. 

RFD03<0>, 

RFD04<0>, 

RFDBS«0>, 

RFO0G<0>. 

RFD07<0>, 

RFO08<0>, 

RFD09<0>, 

RFOi0<0>, 


64 


RFD11<0>. 
RFD12<0>. 
RFD13<0>. 
RFO14<0>, 
RFD1S<0>, 
RFD1G<0>. 
RFD17<0>. 
RFD18<0>, 
RFD19<0>, 
RFD20<0>, 
RF021 <0> , 
RFO22<0>, 
RFD23<0>. 
RFD2/*<0>, 
RFD25<0>, 
RFD2G<0>, 
RFD27<0>, 
RFD2R<8>, 
RFD29<0>, 
RFD30<0>, 
RFD31<0> 


>v*E x  t  er  na  I .  Connec  t  i  onst'oV 


SETROII:  -SETROM  (CONTROfll ,  C0NTR0M2,  CONTROn3) 


**Recji  sterstVft 


!  F  TSC .  GENERALPURPOSEREG I STERS  P209 

MANGPR  10: 7] <23: 0>, !8  MANTISSA  GEN  PURP  REGS 
MANGPR I N<23:0>, (FICTITIOUS  MANTISSA  INPUT 
EXPGPR [0:7] <7j  0>, 18  EXPONENT  GEN  PURP  REGS 
EXPGPR1N<7:0>, (FICTITIOUS  EXPONENT  INPUT 

! F  TSC . UORK I NGREG I S  TERS  P:209 


MANUR [0s 7] <23: 0>, !8  MANTISSA  WORKING  REGISTERS 
EXPUR [0:7]<7:0>, !8  EXPONENT  UORK I NG  REGISTERS 
MANEXTREG<23:0>: -MANUR  [4J  <23: 0>,  IMANTISSA  EXTENSION  REGISTER 
EXPEXTREG<7: 0>: -EXPUR  [4] <7:0>, 'EXPONENT  EXTENSION  REGISTER 
MANt1EMDAT<23: 0>s -MANUR [5J<23:0>,  IMANTISSA  MEMORY  DATA 
EXPMEMDAT <7 :  0> :  -EXPUR  I5J  <7: 0> ,  !  EXPONENT  MEMORY  DATA 
MANMEMA00<23: 0>: -MANUR CGJ <23: 0>,  IMANTISSA  MEMORY  ADDRESS 
E XPMEMADO <7 :  0> :  -EXPUR  [G] <7 : 0> , I  EXPONENT  MEMORY  ADDRESS 
MANPC<23:0>: -MANUR (7) <23: 0>. IMANTISSA  PROGRAM  COUNTER 
EXPPC<7: 0>: -EXPUR  [7] <7: 0>, 'EXPONENT  PROGRAM  COUNTER 
MANURIN<23:0>. IFICTITIOUS  MANTISSA  INPUT 
EXPURIN<7:0>, 'FICTITIOUS  EXPONENT  INPUT 
MANUX<23:0>, IMANTISSA  UX  OUTPUT 
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i  1 1  i-nantfcL'ii 


J 


r  j 


URYB<31:0>, (URYB  OUTPUT 

MANURYB<23:0>:-URYB<31:8>,  (MANTISSA  URYB  OUTPUT 
EXPURYB<7 1 0>:  -URYB<7: 0>,  '.EXPONENT  URYB  OUTPUT 
EXPUX<7: 0>, (EXPONENT  UX  OUTPUT 


' !  F  TSC . 1 NSTRUC T I ONREG I STERP209 ,213 

INR<31:0>, (INSTRUCTION  REGISTER 
RA<2:0>:-INR<21:19>, (SEE  P 60 
RB<2:0>: ■INR<24s22>, 

(OTHER  REGISTERS 

HSU1<1S:0>. ! HARDWARE  STATUS  WORD  1 
HSU2<31 i 0>, (HARDWARE  STATUS  WORD  2 
MRAR<15:0>. (MOST  RECENT  ADDRESS  REGISTER 
MONMSKREG<31 : 0>, (MONITOR  MASK  REGISTER  (REALLY?) 


(FTSC.PIN  (PRIORITY  INTERRUPT  NETWORK)  P229  FF 

PERMSKnEG<31:0>. (PERIPHERAL  MASK  REGISTER 
INTREQREG<7:0>. (INTERRUPT  REQUEST  REGISTER 
(HOW  IS  THIS  LOADED?  SEE  23G  ANO  112. 

(RTI  AND  ARFLT  ARE  LOADEO  FROM  INSIDE  CPU. 

(THE  BITS  CORRESPOND  TO  INTERRUPTS  IN  THE  ORDER 
(GIVEN  ON  P74  FOR  INTMSKREG. 

I NTREQFF<7s0>, (INTERRUPT  REQUEST  FLIPFLOPS 

REQPRIORITY<31:0>,  (HIGHEST  ON-BIT  OF  l NTREQFF 
INTM5KREG<7:0>, (INTERRUPT  MASK  REGISTER 
PENDING<7:0>, (PENDING  INTERRUPTS  REGISTER 
PRIORI TYLEVEL<31:0>. (PENDING  INTERRUPT  PRIORITY  LEVEL  P112 

INPROCFF<31:0>, (INTERRUPT  IN-PROCESS  FLIPFLOPS 

ENAD I SFF <0>  !  ENABLE/O I  SABLE  FL I PFLOP  ( 1  -D I  SABLE?) 


VnVALUi'nV 


(FTSC.ALUINPUTSELECTOR  P.208 

(MANTISSA 

MANINA<23:0>, (MANTISSA  ALU  A  INPORT 
MANA25<2S:0>. (EXTENDED  INPUT  FOR 
(CALCULATING  OVERFLOW  AND  CARRY 
MANINB<23s0>, (MANTISSA  ALU  B  INPORT 
MANB25<2S»0>, 


(EXPONENT 


EXPINA<7i0>, ! EXPONENT  ALU  A  INPORT 
EXP AO<S:0>. 

EXPINB<7:0>, (EXPONENT  ALU  B  INPORT 
EXPB3<8:0>. 

•FTSC. FUNCTION IN VERS  I  ON  P.207 

! MANTISSA 

f1ANC!N<0>.  (MANTISSA  CARRYIN 
MANSELECT<3:0>, (MANTISSA  S0-S3 
INVMFN<0>. (MANTISSA  INVERTER 
EXPCOUT<0>, (EXPONENT  ALU  CARRY-OUT 

(EXPONENT 

EXPC I N<8>, (EXPONENT  CARRY  IN 
EXPSELECT<3:0>. (EXPONENT  S0-S3 
I NVEFN<0>. (EXPONENT  INVERTER 


(FTSC. ALUFUNCTIONSELECTOR  P.20G 

(MANTISSA  ALU  OUTPUT  FUNCTION  (IN2-0) 

MANOVF<0>, (MANTISSA  OVERFLOU 
MANCOUT<0>, (MANTISSA  CARRY  OUT 


(EXPONENT  ALU  OUTPUT  FUNCTION 


EXPOVF<0>, (EXPONENT  OVERFLOU 

(FTSC. AUTOMULDI VSUBP222 

(AUTOMULT  I  PLY  FUNCTION  P224 

(THIS  IS  A  VERY  TENTATIVE  VERSION 

AUTOMULFN<3:0>, (AUTO  MULTIPLY  BITS 
INVERTOR<0>:-AUTOMULFN<3>.  (INVERT  ALU  FUNCTION 
ALU8LS<0>:  »AUT0MULFN<2>,  (ALUB  LEFT  SHIFT 
ALUBZ<0>:-AUTOMULFN<1>. (ALUB  ZEROS 
CRYSTS<0>:-AUTOMULFN<0>, (INTERNAL  CARRY  STATUS 
MULBITS<1j0>, (MULTIPLIER  BITS 


(FTSC. ALUOUTPUTS  P204 

SUM<31s0>, (SUM  OUTPUT 
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ZOT8<0>, 'ZERO  OETECT  SIGNALS 
ZDT24<0>, 

ZDT32<0>, 

FDT32<0>, (FULL  DETECT  SIGNAL 
CRY003<0>, 'MANTISSA  CARRYOUT 
OVF8<0>, 'EXPONENT  OVERFLOU 

(UHAT  ABOUT  MANTISSA  OVERFLOU? 

EXG23<0> ! -1  IFF  EXPONENT  U.E.SUM<7i0)>  GTR  23 


VnvS  i  gna  I  o.  F  l  i p f  |  ops** 

! F  TSC . ENOCOND I T I ONSGENERATOR  P223 


(NOTE  THE  QUESTION  MARKS  BELOU! 

ENOCONDS<12:0>.  ‘LIST  OF  ENOCOND I TIONS 
SUMMR3<0>:  «ENDC0N0S<12>, 
SUMM2RS<0>:*-ENDCONDS<11>. 

SUMMLS<0>: =ENDCONOS<10>. 

SUMM2LS<0> :  -=EN0C0NDS<9> . 

SUMELS<0>:  -F.NDC0NDS<8>, 

SUME2LS<0>: »ENDC0N0S<7>. 

URYMRS<0>: -FNOCONOS<G>. 

URYM2RS<0?j =ENDCONDS<5>, 

URYMLS<0>: -ENDC0NDS<4>. 

URYM2LS<0>: *EN0C0N0S<3>. 

URYER3<0>: -ENDC0NDS<2>, 

URYELS<0> j -ENOCONDS<l>. 

URYE2LS<0>s -ENDCONDS<0>, 

IFTSC.FSFGIFLAG  AND  SPECIAL  FUNCTION  GENERATOR) 
(P.226.94 

EXTADD<0>. (EXTERNAL  (TO  THE  CPU)  ADDRESS  SIGNAL 
ROMAOO<0>, (RECONFIGURATION  ROM  ADDRESS 
HSU1CN<0>, (HAROUARE  STATUS  UORD  1  ENABLE 
HSU2EN<0>, (HAROUARE  STATUS  UORO  2  ENABLE 
LDnMRAR<0>,  (LOAD  MRAR;  HOU  IS  THIS  SET?  SEE  229. 
PERM5K<0>, (PERIPHERAL  MASK  SIGNAL 
I NTMSK<0>, (INTERRUPT  MASK  SIGNAL 


MONMSK<0>, (MONITOR  MASK  SIGNAL 
RHTIME<0>, (READ  HARDENED  TIMER  SIGNAL 
PROFLAG<2;0>. (PROGRAM  FLAGS 

I NRPT<0>, (INTERRUPT  SIGNAL  FROM  PIN  TO  ROM  SEQUENCER 
FLTINT<0>, I FAULT  INTERRUPT  SIGNAL 
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(FTSC. ILLECALOPCOOEDETECTOR  P213 

1LLOPC<0>, ! ILLEGAL  OPCODE  SIGNAL 
FETCHMAX<1S:0>. (MAXIMUM  VALUE  FOR  FETCH  OPCODES 
STOREMAX<15:0>. IMAXIhUM  VALUE  FOR  STORE  OPCODES 


! FTSC. OVERFLOW  01  VIDE  CHECK  AND  CARRY  OUT  STATUS  FLIP  FLOPS  P221 
! (FTSC.0VFD1 VCRYFF) 

OVFF<0>. IOVERFLOU  FLIP  FLOP 
CRYFF<0>, ! CARRY  OUT  FLIP  FLOP 
DIVFF<0>. 'DIVIDE  STATUS  FLIP  FLOP 
ARFLT<0>. (ARITHMETIC  FAULT  SIGNAL 
FCHSTR<S:0>. (CPU  FETCH/STORE  CONTROL  SIGNALS 


! FTSC . GENERALPURPOSEFL I PFLOPS  P219 

GPSF01<0>, (GENERAL  PURPOSE  FLIP  FLOP  l 
GPSF02<0>, (GENERAL  PURPOSE  FLIP  FLOP  2 
GPSF03<0> (GENERAL  PURPOSE  FLIP  FLOP  3 


rtrtCPU.  BlJSOOiVrt 


(FTSC.CPUFETCHANDSTORE  P230 

IMAB<15;0>. (CPU  ADDRESS  BUS 
IMOB<31:0>!CPU  DATA  BUS 


**Loop.  T  i  mervnSr 


(FTSC.L00PTIMERP219 

SEQ11<0>, (LOOP  BRANCH  CONDITIONS 
SEQ1 5<0> , 

SEQ22<0>. 

SEQ30<0>, 

SEail3<0>, 

CPUCLK<0>, (CPU  CLOCK  PULSE 
COUNTER<G:0>, (COUNTS  UP  TO  113  PULSES 
ASUBFF<0>, (AUTOSUBTRACT  FLIP  FLOP 
INTMUL<ls0>, (FOR  AUTOMULTIPLY 
FLOMUL<li0> 


»v»vProce  s  se  s«v*v 
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! F  TSC . ROMSEQUENCER  P2 13.217 

SEQUENCER :- 

BEGIN 

IF  FLTINT-> 

(RAD-0  NEXT IP115. 218 
I  MDB-RECONF  I  GROM  19]  NEXT 
PERM3KREG<7>-1  NEXT 
LEAVE  SEQUENCER)  NEXT 
IF  I LLOPC«> IP218 
(RAD-2  NEXT  LEAVE  SEQUENCER) 

NEXT 

RAD<9: 6>*-RF02<9:  G>  NEXT 
DECODE  RF01  -> 

BEGIN 

0:  -  (RAD<5>-R0NA4:RAD<4>-R0NA5;RAD<3>-R0MA6s 
RAD<2>-R0MA7j RAD<1  >-RO(1A8; RAD<0>-ROMA9) . 

1 :  -  (RAD<S>-INR<30>;RAD<4>*-INR<22>;RAD<3>*-1NR<28>: 

RAD<2>-INR<27>;RAD<1>~INR<26>;RAO<0>-INR<2S>). 

2:  -  (RA0<S>-R0MA4  •  RAD<4 >-EXG23 ;  RAD<3>-QVF8 ;  RAD<2>-SUM<0> : 
RAD<I>-ZOT8;RAO<0>-SUn<7>)  . 

3:  -  (RAD<S>-R0nA4:  RAD<4>-SUNm  :RA0<3>*-ZDT24;RAD<2>-SUN<29>: 

RAD<1 >-SUn<30>;RAD<0>-SUn<31>) . 

4:  -  (RAD<3>-RnNA4;RAD<4»-R0NA5;RA0<3>«-lNR<31>;RAD<2>«-INR<18> 
RAD<1>-INR<17>:RAD<0>-INR<1G>) , 

5:  -  (RAD<5>-R0MA4;  RAD<4>-R0MA5:RAD<3>*-0VF8sRAD<2>«-SUt1<23>; 

RAD< 1 >-SUn<30> ; RAD<0>-SUn<31  > ) , 

G :  -  ( RAO<S>-ROMA4 ;RAD<4 >-ROMA5 ;  RAD<3>«-ZDT24 ;  RAD <2 > -SUM <29 > : 

RAO<l:»-SUM<30>sRAO<0>-SUn<31>) , 

7 :  -  (RAD-.5>-R0MA4 :  RA0<4>~R0MA5;  RA0<3>‘-ZDT32;  RAD<2>«-SUM<29>: 

RAD<1  >*-SUM<30>: RAO<0>-SUM<31>) , 
8:-(RA0<5>-R0MA4;RA0<4>-R0MA5;RAD<3>-0VF8;RAD<2>«-SUM<27>; 

RAD<  1  >-SUM<29> :  RAD<0>-SUf1<28> ) , 

9:  -  (RAD.:5>-R0MA4  •  RAD<4>-R0MA5s  RAD<3>«-ROMAG; RAD<2>-GPSF03; 
RAD<1>-GPSF02:RAD<0>-GPSF01) , 

1 0:  -  (RAD<S>-R0NA4  •  RAD<4>-R0MA5:  RAD<3>«-ROMAG;  RAD<2>*-SUM<0>: 
RAD<1>-ZDT8:RAD<0>‘-SUM<7>) , 

11 :  -  (RAD<5>-ROMA4;RAD<4>-ROnA5:RAD<3>*-ROMAG;RAD<2>«-ZDT32; 

RAD<1  >-SUM<0>; RAD<0>*-SUM<31>) , 

12:  ■  (RAD<5>-R0MA4;  RA0<4>-R0MA5;RAD<3>-R0MAG;RAD<2>*-R0MA7} 
RAD<1>-SUMM1 ;RAD<0>-SUM<31>) , 

13:  -  (RAO<5>-ROnA4;RAD<4>-ROMA5;RAD<3>-ROMA6sRAD<2>*-ROMA7: 

RAD<1 >-ZOT24;RAD<0>-SUM<3l>) , 

14:-  (RAD<5>-R0MA4 ; RAD<4>-R0MA5 : RAD<3>-R0MAG ; RAD<2>«-R0MA7 ; 

RAD<1>-ZDT32:RAD<0>-SUM<31>) , 

15:-  (RAD<S>-R0riA4 ;  RAD<4>-R0MA5;  RAD<3>-R0MAG :  RAD<2>-R0MA7 : 

RAD<1>-SUM<0>:RAO<0>-SUM<1>) , 
lG:-(nAD<5>-R0MA4;RAD<4>-R0f1A5:RAD<3>-R0MAG:RAD<2>-R0MA7| 
RA0<1 >-SUM<8> : RAD<0>-SUM<9> ) , 

17:-  (RA0<S>-R0MA4 • RA0<4>-R0MA5j  RAD<3>-ROMAGi RAD<2>-R0MA7» 
RAO<1>-SEQ113;RAO<0>-OVF8) . 

18:  -  (RAD<S>-ROMA4jRAD<4>-ROMA5;RAO<3>-ROMAGjRAD<2>*-ROMA7l 
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RAD<1>~CNTRL;RAD<0>*-INRPT) . 

1 3:  -  (RAD<5>«-R0MA4 ; RAD<4>«-R0MA5 : RAD<3>-R0MAG: RAD<2>*-R0MA7 
RAD<1 >-R0MA8: RAD  -.0>-ZDT32) , 

20:  -  (RAD<S>-R0MA4;  9AD<4>*-R0MA5;  RAD<3>*-R0MA6;RAD<2>*-R0MA7 
RAD<1>*-ROHA3;RAD<0>‘-SEQ11) . 

21 :  -  (RA0<S>-R0MA4:RAD<4>*-R0MA5;RAD<3>*-R0MAS:RAB<2>*-R0MA7 
RAD<1>-ROMA8:RAD<0>-SEQ15) . 

22: *> (RAD-  5>«-R0MA4jRAD<4>*-R0MA5:RAD<3>«-R0MAG;RAD<2>«-R0MA7 
RAD'-l  >-ROMA8;RAO<0><-SEQ22) , 

23:  -  (RAD-  S'-*-R0nA4;RAD<4>‘-R0MA5:RAD<3>‘*R0t1A6;RA0<2>«-R0f1A7 
RA0<1>-R0MA8;  RAO<0>*-SEQ30) , 

24:  -  (RAD'-5>*-R0MA4 :  RA0<4>-R0MA5; RAD<3>-R0MA6; RAD<2>«-R0MA7 
RAD<1  >«-R0MA8;  RAO<0>*-SUM<7>) , 

25:  -  <RAD<S>-R0riA4:RAD<4>-R0ttAS:RAD<3>-R0nA6;RAD<2>-R0nA7 
RAD<l>-ROnA8:RAD<0>*-OVFF) , 

26:  -  (RAD<5>*-R0MA4;RAD<4>-P0MA5:  RAD<3>*-R0MA6;RAD<2>»-R0MA7 
RAD<1>-ROHA8;RAD<0>-CRYFF) , 


'>7. 


23: 
30: 
31 : 


(RAD<5> 
RAD<1> 
(RAD<5> 
RAD<1> 
(RAD<5> 
RAD<  1  > 
(RAD<5> 
RAD<1> 
(RAD<5>- 
RAD<1> 


R0MA4 

ROMAS 

RQMA4 

ROMAS 

R0MA4 

ROMAS 

R0MA4 

ROMAS 

R0MA4 

ROMAS 


RAD<4>. 

RAD<0>' 

RAD<4>< 

RAD<0>' 

RAD<4>. 

RAD<0>' 

RA0<4>' 

RAD<0>' 

RAD<4>< 

RAO<0>< 


-ROMAS;  RAD<3>. 
-F0T32). 
-ROMAS;  RAD<3>' 
-Z0T8). 

-R0MA5:RAD<3>' 
-MONMD) . 
-R0MA5:RAD<3> 
-SUM<31>), 
-ROMAS:  RA0<3>. 

■anode) 


-ROMAS :  RAD<2>«-R0MA7  5 
-ROMAS:  RAD<2>*-R0MA7  ; 
-ROMAS ;RAD<2>-R0MA7; 
-ROMAS; RAD<2>-R0MA75 
-R0MA6 :  RAD<2>«-R0MA7  j 


END 

NFVT 


DECODE  1NR<18: 16>«> 
BEGIN 

0:-  AMODE-O. 

0THERU!SE;-AM0DE-1 

END 

END,  ! OF  SEQUENCER 


NEXTROMUORD: « 

BEGIN 

mcunnDi-cofjTROMi iradj  nextinext  rqmuord 
MIC.U0RD2-C0NTR0M21RAD)  NEXT 
niCU0RD3-C0NTR0M3lRAD)  NEXT 
RF01  <4 : 0>-M I CU0RD1 <31 : 27>NEXT 
RF02<3:  0>~MJCUORD1<2G:  17>NEXT 
RF03<2: 0>-MICUORDl<16: 14>NEXT 
RF04<2: 0>-MICUORDl<13: 11>NEXT 
RF0S<2: 0>-MJCUORDl<10: 8>NEXT 
RF0G<2: 0>*-MI  CU0R01  <7 :  5>NEXT 
RFO7<0>-M1 CU0RD1<4>NEXT 
RF0S<0>-M1 CU0R01 <3>NEXT 
RF03<2: 0>-Ml CU0RD1<2: 0>NEXT 
RF 1 0<2 :  0>*-M  I  CU0R02<31 : 29>NEXT 
RF11<0>*-MICWORO2<28>  NEXT 
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RF12<0>-t1ICUORO2<27>  NEXT 
RF1 3<0>-N! CU0RD2<2S>  NEXT 
RF14<0>-niCUORD2<25>  NEXT 
RF1S<2:  0>-Ml  QJ0RD2<24: 22>  NEXT 
RF 1  G<2: 0>-M ! CU0RD2<21 : 19>  NEXT 
RF17<3:0>-MICUORD2<18: 15>  NEXT 
RFlS<3:0>-rilCUORO2<14:ll>  NEXT 
RFl,J<O>-mcUORD2<10>  NEXT 
RFr0<o>-mcunnD2<9>  next 
RF21<0>-rilCUOnD2<8>  NEXT 
RF22<2:  0>«-f1ICUORD2<7:5>  NEXT 
RF23<B>-f1ICU0R[)2<4>  NEXT 
RF24<0>-riICUORD2<3>  NEXT 
RFZ5-.0>-niCUDRD2<2>  NEXT 

RF2G<0>-riICUORD2<l>  NEXT 
RF27.:0>U1ICUORD2<0>  NEXT 
RF28''0>-HI  CUnR03<13>NEXT 
RF 2'J-  0>-H  1  CUC*RD3<  1 2>NEXT 
RF  30  ii  >  -N I CUCIRD3  <  1 1  >NEX  T 
RF31 <4: 0>-Ml CUORD3<10: G>NEXT 
RF32<0>m1I CUPRD3<5>NEXT 
RF33«'0'‘-NICUPRD3<4>NEXT 
RF34<0>^niCUDRD3«-3>NEXT 
RF35<0>-MICUIORD3<2>NEXT 
RF3G-  0>-riICUORD3<l>NEXT 
RF37<3>«-NICUORD3<0> 

END.  !0F  NEXTROHUORD 


! F  TSC . ROMFUNC T i ONDECOOER 


F.220 


DECODER: 

BEGIN 

RFD00-0 

RFD0U0 

RFU02-0 

RFD03-0 

RFD04-0 

RFD05-O 

RFnnn-o 

RFD07-0 
RFD08-0 
RFQOD-0 
RFO10-0 
RFD1 1-0 
RFU12-0 
RFD13-0 
RFD14-0 
RFO15-0 
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MICROCOPY  RESOLUTION  1ESI  CHARI 


RFD16-0  NEXT 
RFD17-0  NEXT 
RFD18-0  NEXT 
RFD19-0  NEXT 
RFO20-0  NEXT 
RFD21-0  NEXT 

RFD22-0  NEXT 
RFD23-0  NEXT 
RFO24-0  NEXT 
RFD25-0  NEXT 
RFO2G-0  NEXT 
RFD27-0  NEXT 
RFO28-0  NEXT 
RFD23-0  NEXT 
RFO30-0  NEXT 
RFD31-0  NEXT 


DECODE  RF31  . 
BEGIN 

Bj-RFOnO-l, 
ls-RFDOl-l. 
2:-RFO02-l. 
3:-nrDQ3-l. 
4:-RF00W, 
5:-nrD!15-l. 
6: -RFO0G-1 , 

7:  -RFD07*-1 , 

8:  «RFO08«-1 , 

3:  "RFO03*-1 , 
10: ^RFD10-1 , 


Uj-RFDlUl. 
12: -RF012-1 . 
13:-RF013-1, 
14 :  »RF014»-1 , 

15: -nroiG-i . 
lGi-RFDlG-l, 
17:-RFD17-1, 
IS:  -RF018«-1 , 
19:-RFD19-1. 
20: -RFO20-1 , 
21 : -RFD21-1 , 
22: •DF022-1 , 
23: -RFD23-1 , 
24:  "•RFD24«-1 , 


25:-RF025-l, 


2G:  "-RFD2G-1 , 
27:  «nFD27*-l , 
28: -RFD28-1 , 
29: -RFD29-1 , 
30:  »RFD30*-1, 


31 :  »RFD31*-1 
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ENO 

END. 10 F  OECOOER 


!  THE  NEW  VALUES  OF  MANOVF  AND  MANCOUT  STILL  HAVE  TO  BE  CALCULATED 
•ALONG  UITH  HANOUT  0ELOU. 


MAN0UT<24: 0>: • 

BEGIN 

DECOOE  RF37-> 

BEGIN 

0:  ■  <MANA25*24: 0><«MANINA  NEXT  MANB25<24:0><-MANINB  NEXT 
(DECOOE  MANSELECT  -> 

BEGIN 

0 :  «>  M A  NC  OU  T  ^M ANOUT  to  ( M AN A25  <  24 : 0  >  AND  MANB25<24: 0>) , 

1 :  -NANCOUT^riANOUT-  (MANA2S<24: 0>  EQV  MANB2S<24: 0>) , 

2:«MANC0UT.=>PANOUT+(NOT  MANA25<24i0>)  +  BaMANCIN, 
3:-NANCOUT<.»MANOUT*-MANB25<24:0>  +  BaMANCIN, 

4 :  -flANCOUToflAf  JOUT«-(NOT  t1ANB25<24: 0>)  +  BaMANCIN. 
5:-NANCOUfaMANOUT-MANA25<24:0>  +  BaMANCIN, 

G:  -MANCOUTaflANOUT.-MANA25<24: 0>  +  MANB2S<24: 0>+0aMANCIN, 

7:  «riANCOUTi:.NANOUT*-#I  77777777+ (0@MANCIN) , 

8:  »MANCOUTanANOUT.-MANB25<24: 0>+NOT  MANA25<24: 0>+  BaMANCIN,  ISometimes  it 
! looks  like  MANA25<24:0>  above  should  be  just  MANINA.  Similarly  in  next  line. 
9 :  -MANCOU  T,  );iAN0UT-MANA25<24 :  0>+NOT  MANB25<24  s  0>+0®MANC  I N , 

10:  »MANC0UTaMAN0UT«-MANA25<24: 0>+-  (0@NQT  MANCIN) , 
ll:-riANCOUT^1ANOUT-(NOT  MANB25<24: 0>)+  -  (0@NOT  MANCIN), 

12:  -MANCOUTaMANOUT-MANB25<24:0>+-(0@NOT  MANCIN) , 

13:«.MANC0UTariAN0UT-(N0T  MANA2S<24: 0>)  +  -  (0eNOT  MANCIN), 

1 4 ;  »MANC0UTa?1AN0UT •- (MANA2S<24 :  0>  XOR  MANB25<24: 0>) , 

1 5 :  •MANCOUTaMANOUT*- (MANA25<24 j 0>  OR  MANB25<24:0>) 

ENO) ) . 

1 : - (MANA25<-MANINA  NEXT 

MANB2S< -MAN I NB  NEXT 

IF  ALUBLS->MANB25-MANB2S  SL0  1  NEXT 

IFOR  AUTOMULTIPLY  SIGN-EXTEND  MANTISSA  TUO  BITS  BEFORE  SHIFTING 
I  BUT  NOT  EXPONENT? 


(DECOOE  MANSELECT  -> 

BEGIN 

0:  -MANCOUT<?MANOUT«-  (MANA25  AND  MANB25) , 

1 :  -MANCOIJTaMANOUT.-  (MANA25  EQV  MANB25) , 

2:-MANC0UTaf1AN0UT.-(N0T  MANA25)  +  BaMANCIN, 

3:-MANC0UT«nAN0UT-MANB25  +  BaMANCIN, 

4: *MANCOUTaMANOUT»- (NOT  MANB25)  +  BaMANCIN, 

5:  ■MANC0UTaMAN0UT«-MANA25  +  BaMANCIN, 

G:  ■MANC0UTaMAN0UT»-MANA25  +  MANB2S+0aM ANC I N , 

7t  «MANCOU T i»MAN0U T*-tf  1 77777777+  (BaMANCIN) , 

8: •MANCOUT<»MANOUT»-MANB25+NOT  MANA25+  BaMANCIN,  ISometimes  it 
!  looks  like  MANA25  above  should  be  just  MANINA,  Similarly  in  next  line. 
9*  »M ANCOU T  «M ANOU  T +MAN A25+N0 T  MANB25+0®MANCIN, 
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10:  "ttANC0UT<*MANOUT«-f1ANA25+-  (BsNQT  MANC1 N) , 

1 1 :  «MANCOUT@NANOUT*-  (NOT  MANB2SW  -  I0«NOT  DANC1N) , 
12:  -MANCOU  T @M  AN0UT.-MANB2S+-  (8@N0T  I1ANCIN) , 

13:  »MANCOUTc->MANOUT*- (NOT  MANA25)+  -  (0@NOT  flANCIN). 
14:  -NANCOUT@MANOUT«- (MANA25  XOR  MANB25) , 

1 5 :  -flANCOUT wMANOUT*-  (MANA25  OR  MANB25) 

END) ) 

END 

END. ! OF  MANOUT 


!THE  NEU  VALUES  OE  EXPOVF  AND  EXPCOUT  MUST  STILL  BE  CALCULATED  ALONG 
IUITH  EXPOUT  BELOU.  SEE  LINES  8-13  BELOU. 

EXP0UT<S:0>:  ■ 

BEGIN 

EXPAD<-EXPINA  NEXT 
EXPBO<-EXPINB  NEXT 
IF  ALUBLS- >EXPB9-EXPB9  SL0  1  NEXT 
I DECODE  EXPSELECT  -> 

BEGIN 

0:  -OXPCOUT@!'XPOUT.-EXPA9  AND  EXP33, 

1 :  •EXPC0UT.»EXP0UT»-EXPA9  EQV  EXPB3. 

2: -DECODE  EXPCI N->  (EXPCOUT, »EXPOUT-NOT  EXPA9, 

EXPCOUT  i?EXPOUT  -NOT  EXPA9  +  0*RF19  +B»1), 

3:  -DECODE  EXPCIN-> (EXPC0UT@EXP0UT-EXPB3, 

EXPC0UT«?EXP0UT-EXPB9  +0*RF19  +0*1), 

4:  -DECODE  EXPCIN-> (EXPCOUT@EXPOUT.-NOT  EXPB3, 

EXPCOUT@EXPOUT.-NOT  EXPB9  +0*RF19  +0*1). 

5: -DECODE  EXPCIN->(EXPC0UT@EXP0UT*-EXPA9, 

EXPCOUTsEXPOUT-EXPAS  +0*RF19  +0*1), 

G:  -EXPC0UToEXP0UT«-EXPA9  +  EXPB9  +  0@EXPCIN, 

7:  -EXPCOUT.?EXPOUT»#777+(0pEXPCIN)  , 

8:  -EXPCOUT@EXPOUU£XPB9+NOT  EXPA9  +  0@EXPCIN, 

9:  -EXPCOUT@EXPOUT+EXPA9+NOT  EXP09  +  0<?EXPCIN, 

10:  -DECODE  EXPCIN->(EXPCOUT@EXPOUT-EXPA9+-(0*RF19+1) , 

EXPCOUT  @EXPOU  T  -£XPA9 ) , 

1 1 :  -DECOOE  EXPCIN->  (EXPCOUT@EXPOUT.-NOT  EXPB9+- (0*RF19+1) , 

EXPCOUT@EXPOUT.-NOT  EXPB9) . 

12:  -DECODE  EXPC!N->(EXPCOUT@EXPOUT-EXPB9+-(0«RF19+1) , 

EXPC0UT@EXP0UT«-EXPB9) , 

13:- DECODE  EXPCIN-> (EXPCOUT@EXPOUT-NOT  EXPA9+-(0*RF19+1) , 

EXPCOU T @EXPOUT-NOT  EXPA9) , 

14:  -EXPC0UT@EXP0UT-EXPA9  XOR  EXPB9, 

15:  -EXPC0UT@EXP0UT-EXPA9  OR  EXPB3 
END) 

NEXT 

0VFS-EXP0VF-EXP0UT<8>  XOR  EXP0UT<7> 

END,  *  OF  EXPOUT 
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!FTSC. FSFG (FLAG  AND  SPECIAL  FUNCTION  GENERATOR) 
‘P.226.94 


FSFG: - (FLAG  AND  SPECIAL  FUNCTION  GENERATOR 
BEGIN 

HONMSK-RHTINE-PROFLAG-0  NEXT 

EX T ADO-ROM ADD-HSU 1  EN-HSU2EN-PERNSK-I NTMSK-0  NEXT 

DECODE  I  HAD  -> 

BEGIN 

"FSOOs ■  HSU1EN-1, 

"FSOl : -  HSU2EN-1, 

"FS02s  •  MONMSK-1 , 

"FS03:  -  PERtKK-l, 

"F804 : -  INTMSK-l, 

"FS0G: -  RH TINE-1. 

!  IF  I  NAD  GTR  "F80S  AND  INAB  LSS  “F809  ->  ERROR? 
"FS03: "PR0FLAG-IMAB<2:8>, 

"FSJJA :  -PROFLAG- 1 MAB<2 : 0>, 

"FSHB: -PROFLAG- I MAB<2:0>, 

"F80C : -PROFLAG- INAB<2: 0> , 

M F SOU: -PROFLAG- I MAB<2:0>. 

"F80E :  -PROFLAG- 1  NAB<2 :  0> . 

"FS0F s -PROFLAG- 1 NAB<2:0> . 

OTHERUISEs - ! SEE  P  G9  . 

((IF  ((INAB  GEQ  ”F0O 0)  ANO  (I NAB  LEO  ”F7FF))-> 
ROMAOO-1)  } 

(IF  ((INAB  LSS  "F000)  OR  (INAB  GTR  "F7FF))-> 
EXTADO-D) 

END 

ENO. I OF  FSFG 


•FTSC.ILLEGALOPCOOEOETECTOR  P219 


DETECTOR; - 
BEGIN 

IF  RF012«> ( I LLOPC-0  NEXT  LEAVE  DETECTOR)  NEXT 
IF  (RFD01  OR  RFD11 ) ■  > 

( I LLOPC- I NOB<20>  NEXT  LEAVE  DETECTOR)  NEXT 
•OR  INDB<21>?  ON  P64  IT  SAYS  BIT11-INDB<20> 
•BUT  ON  205  IT  SHOUS  BIT10-INDB  <21>  AS  INPUT. 

DECODE  INR<31>»> 

BEGIN 

0;-  IF  0(»INR<30;2S>  GTR  FETCHNAX  -> I LLOPC-1 , 
It-  IF  0i»INR<30:25>  GTR  STORENAX  ->ILLOPC-l 
END 

END. !OF  DETECTOR 


00 


LOOP:- 

BEGIN 

PENOING-PENOING  OR  INTREQFF  NEXT 

(IF  REQPRIORITY  LEQ  PRIORI TYLEVEL  ->LEAVE  LOOP)  NEXT 

PRIORI TYLEVEL  -  REQPRIORITY  NEXT 

(IF  PRIORI TYLEVEL  LEQ  INPROCFF  ->  LEAVE  LOOP)  NEXT 

(IF  ENADJSFF  ->  LEAVE  LOOP)  NEXT 

INRPT-l  NEXT 

IF  RF27  ->JNTREQREG<PRIORITYLEVEL>  -  0  NEXT 
INPROCFF<PRIORITYLEVEL>  «-  1 
ENO, !OF  LOOP 


PRIORITY:. 

BEGIN 

REPEAT 

BEGIN 

REQPRIORITY  -  REQPRIORITY  +  1  NEXT 
(IF  (INTREQFF  SR0  REQPRIORITY)  EQL  1  -> 

LEAVE  PRIORITY)  NEXT 

(IF  (REQPRIORITY  EQL  8)  ->  (REQPRIORITY  -0  NEXT 
LEAVE  PRIORITY)) 

END 

ENO,  IREQPRICRI TY.the  level  of  highest  interrupt  requested. 


IFTSC.PIN  (PRIORITY  INTERRUPT  NETWORK)  P229  FF 


PIN;. 

BEGIN 

IF  PERMSK  -  >PERMSKREG*- 1  MOB  NEXT 
IF  FLT I NT->PERMSKREG<7>*.1  NEXT 
IF  ARFLT.>INTREQREG<7>*-1  NEXT 
!AUD  THE  OTHER  PRIORITIES  HERE. 

IF  PERMSKREG<7>  « > I N TREQFFa I NPROCFF *-0  NEXT 
IF  INTMSK  INTMSKREG-IMDB  NEXT 

IF  NOT  PERI13KREG<7>  -> INTREQFF  -  { I NTREQREG  AND  NOT  INTHSKREG)  NEXT 
!  IF  FLTINT  ->...  LEAVE  PIN  NEXT 

I  IF  ILLOPC  •>...  LEAVE  PIN  NEXT 

REQPRIORITYc— 1  NEXT 
PRIORITY!)  NEXT 
LOOPO  NEXT 

IF  (RFQ10  OR  RF27  OR  PERNSKREG<7>)  ->  INPROCFF-0  NEXTIALL  OF  THEM. 
•THERE  STILL  MAY  BE  SOME  IN  PENDING 

IF  (RFO0I  OR  RFO10) *>ENAD I SFF*-I MDB<23>  NEXT 
IF  RFD13  «>ENADISFF*-1  NEXT  ' 

IF  RFD12  .>ENAOISFF»-0 
ENO. !OF  PIN 


0  7 


IFTSC.L00PTIMERP219 


TIMERS  - 
BEGIN 

COUNTER-COUNTER  +1  NEXT 

IF  RFD14  •> (C0UNTER-SEQ1 1-SEQ15-SEQ22-SEQ3B-SEQ1 13  -0)  NEXT 


DECODE  COUNTER  -> 

BEGIN 

llt-SEQll-l, 

15s  -SEQ15-1 , 

22:*SEQ22-1, 

30:-SEQ30-l. 

113: -SEQ1 13-1. 

114: -COUNTER-0  ! Maybe  not:  or  Maybe  need  two  countere: 

lone  for  eetting  SEO  and  one  for  counting  Microetepa. 

END 

ENDCOF  TIMER 


**M  i cr o i ne  true  1 1  on. Cyc I a** 

CYCLE  IMA INI : • 

BEGIN 

DELAY  Cl)  NEXT 
RAO-1  NEXT 

FETCHMAX--3S  NEXT  ITHESE  ARE  THE  MAXIMUM  OP-CODES  FOR 

!!NR<31>.0,1  RESPECTIVELY 
ST0REMAX--68  NEXT 
COUNTER-0  NEXT 
REPEAT 
BEGIN 

NEXTROMUORDO  NEXT 
SEQUENCER O  NEXT 
OECOOERO  NEXT 

IF  RF021»  (GPSF01-GPSF02-GPSF03-ASUBFF-0)  NEXT 
IAUTO  MULTIPLY  FN.  P224 

OECOOE  RF37»> (AUTOMULFN-0, 

(DECODE  RF23-> 

BEGIN 

0:-MULBITS-lNTMUL, I  INTEGER  FORMAT 

1 :  -MULB 1 TS-FLOMUL ! FLOAT  I NG  POINT  FORMAT 

ENO 

NEXT 

DECOOE  CRYSTSeMULBITS  -> 

BEGIN 

0I-AUTOMULFN-2, 
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1 1  -AUTOMULFN«-0, 

2 1  •AUT0HULFN*-#15 , 
3$  -AUTOttULFN*-#ll , 
4t  -AUTOriULFNv0, 

5 1  •AUT0MULFN«-4 , 
G!-AUTOHULFNvtfll, 
7j  -AUTO«ULFNw<Sfl3 
END)  ) 

NEXT 


MANUX-flANUR  IRF03J  NEXT 
t1ANURY0**HANUR  [RF05J  NEXT 
EXPUX-EXPURCRF04]  NEXT 
EXPURYB*-EXPUR  (RF061  NEXT 
•  F  TSC .  GENERALPURPOSEREG I STERS  P209 


! F  TSC. ALUI NPUTSELECTOR  P.208 

! MANTISSA 

DECODE  RF20  -> 

BEGIN 

0:  -flANINA-MANGPR  (RA1 . 

1 :  -HAN  I  NA*-f1ANGPR  [RBI 

END 

NEXT 

DECODE  ALUBZ  -> 

BEGIN 

0S-DECOOE  RF21  OR  AMOOE->  (flANI  NB«41ANGPR  IRAJ , HANI NB-flANUX) 

1:  -MANINB«-0 

END 

NEXT 

•EXPONENT 

DECODE  RF20  -> 

BEGIN 

0:  -EXPINA*EXPGPR (RAJ , 

1 :  -EXPINA-EXPGPR  tRBJ 

END 

NEXT 

DECODE  ALUBZ  » 

BEGIN 

0: -DECODE  RF21  OR  AMODE-> (EXP1NB-EXPGPR [RAJ ,EXPINB*EXPUX) 

li-EXPINB-0 

END 


IFTSC.FUNCTIONINVERSION  P.207 

INVERTOR«-(RF3S  AND  INVERTOR)  OR  (RF37  AM)  INVERTOR)  NEXT 

OECOOE  RF23-> 

BEGIN 

0:  -  ( I NVEFN- 1 NVERTORj  I NVMFN.-1 NVERTOR) , 

ls-INVHFN-INVERTOR 

END 

NEXT 

OECOOE  I NVEFN  -> 

BEGIN 

0s  -  (EXPC I  N*-RF24:  EXPSELECT«-RF18) , 

Is  -  (EXPCI N*-NOT  RF24 5 EXPSELEC T *-NOT  RF18) 

END 

NEXT 

IFTSC.  ALUFUNCTIONSELECTOR  P.20G 

! MANTISSA  ALU  OUTPUT  FUNCTION  (IN2-0) 


! EXPONENT  ALU  OUTPUT  FUNCTION 


EXPOUT  0  NEXT 

IF  ASUBFF  ->(INVMFN-RF33)  NEXTIINVERT  CARRY  IN  BITS  TO  MANTISSA. SEE  P  222 
DECORE  INVMFN  -> 

BEGIN 

0s- (OECOOE  RF23  -> 

BEGIN 

0  s  -MANCIN*-  EXPCOUT, 

1  s  -MANC I  N*-RF25 
ENOs 

MANSELECT-RF17) , 

Is -(OECOOE  RF23  -> 

BEGIN 

0s -MANCIN*-  EXPCOUT,  INote  this  deviation!?)  from  the  documentation. 

ls-MANCIN«-NOT  RF2S 

ENOs 

MANSELECT*^OT  RF17) 

END 

NEXT 

MANOUTO  NEXT 

IFTSC. ALUOUTPUTS  P204 
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I f10B-SUtt*-MAN0UT <23t  0>aEXPOUT<7: 0>  NEXT  (Here  I  MiuM  that 

! SUI“LSBEN ,  SUMHSBEN  are  always  on  ao  that 
!any  output  of  the  ALU  goes  to  IMOB  and  SUM. 
SUMM1«41AN0UT<24>  NEXT 


SUMM2-MANC0UT  NEXT 
DECOOE  SUM<31:8>-> 

BEGIN 

0:  -Z0T24«-1, 

OTHERUI SEi  •ZOT24*-0 

END 

NEXT 

DECODE  SUM<7:0>*> 

BEGIN 

0:-2OT8*-l. 

OTHERUI SEi-ZDT8v0 

END 

NEXT 

decooe  sun-> 

BEGIN 

0:  -  (ZDT32»-1  :FOT32«-0) , 

« 7777777777: -  (FOT32-1 ; ZOT32-0) , 

OTHERUISE: -  (FDT32-ZDT32-0) 

END 

NEXT 

EXG23-0  NEXT 

IF  (SUN<7:0>  GTR  23)  OR  (SUM<7t0>  LSS  -23)  «>  EXG23«-1  NEXT 
IFTSC.  ENDCONDI T I ONSGENERATOR  P223 


•NOTE  THE  QUESTION  MARKS  BELOU! 

OECODE  RF22  •> 

BEGIN 

0:  -ENOCONOS*-SUn<0>*SUn<l  >aURYB<31  >«URYB<30>aSUn<31  >aSUM<30> 

•UR YB<31 >«URY8<31 >a (RF25  XOR  INVnFN)a’0aURYB<31>»,80, 

1 1  -EN0C0N03-SUmi«SUnM2®URYB<31  >«URYB<30>*’  00«SUH<8> 

•SUM<9>« (RF24  XOR  INVEFN)a,0aSUn<8>a,00, 

•THERE  IS  STILL  SOME  OOUBT  IF  THE  ABOVE  LINE  IS  CORRECT.  SEE  P223 
2*  -ENOCONOS-’ 1»SUM<31  >«SUM<7>eSUM<6>eSUM<31  >*SUf1<30> 

•SUM<8>aSUM<9>* (RF25  XOR  INVMFN)«’0aSUM<8>a'01. 

3*  -ENDCONDS-’  00®SUM<7>aSUM<6>a’  B0»SUM<8>aSUM<9> 

•  IRF2S  XOR  INVMFN) a*  0*SUM<8>«SUM<31>»SUM<30>, 
4i-ENOCONDS-URYB<8>«URYB<l>aSUM<7>aSUM<S>aURYB<31>aURYB<30> 

•SUM<0>»SUM<l>eURYB<7>aURYB<S>aSUM<0>a IRF24  XOR  INVEFN)a’l, 

St  -ENOCONOS-SUMMl«SUMM2aSUM<7>aSUM<6>*URyB<31  >#URYB<30> 
•SUt1<0>aSUM<l>aURYB<7>#URYB<6>aSUM<0>#' 00. 


G  i  •EN0C0NDS*-SUM<3 1  >«SUf1<31>«SUn<7><»SUf1<G>*URYB<31>#URYB<30> 
•SUM<0>®SUf1<l  >*URYB<7>«URYB<6>»SUM<0>V  11 , 

7*  -ENOCONDS-  ’  00#SUf1<7>«SUM<G>«WR  YB<31  >*URYB<30>«SUt1<0> 
•SUf1<l>*URYB<7>«URYB<6>«SUt1<0>«SUt1<31>®SUf1<30> 

END 

NEXT 


! AUTODIVIDE  FUNCTION  P.225 
IF  RF36-><INVERT0R-SUM<31>)  NEXTIPREVIOUS  SUM 

f AUTOSUB TRACT  FUNCTION 
IF  RFD22->(ASUBFF^1)  NEXT 

IF  RFO07->GPSF01*-1  NEXT 
IF  RFD08->GPSF02-1  NEXT 
IF  RFO09->GPSF03-1  NEXT 


IFTSC . CPUFETCHANDSTORE  P230 


IF  RF2G-> ‘MEMORY  REQUEST ( "SPEED  UP") 

(DECOOE  RF32-> 

BEGIN! ADDRESS 

0:  -IMAB-URYB<15j 8>®EXPURYB, 

lt.IMAB-(URYB<15s8>«EXPURYB)  +  #10000  I  ADO  4096 
END)  NEXT 

IF  LOBMRAR  ->  MRAR*-[MAB  NEXT 

!THE  FLAG  AND  SPECIAL  FUNCTION  GENERATOR  CONES  HERE  (FTSC.FSFG) 
•(STILL  INSIOE  IF 

•SINCE  IT  COMPUTES  THE  VALUE  OF  EXTADD  WHICH  IS  NEEOEO  BELOU. 
FSFGO  NEXT 


DETECTOR!)  NEXT 


•  CRYFF*-0  NEXT ‘OR  IS  RESTORING  ENOUGH?  SEE  BELOU 
!  01 VFF*0  NEXT ‘DITTO 
IF  RFO03«>OVFF*-1  NEXT 
IF  RFO04->OVFF^0  NEXT 
IF  RFD0S->CRYFF*MANCOUT  NEXT 
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I 


IF  RFO06  ->01VFF-1  NEXT 
IF  RFO10->(OVFF-IMOB<21>  NEXT! RESTORING 
CRYFF«-IMDB<19>  NEXT 
01 VFF-IMDB<22>)  NEXT 

I F  RF28->  ( 1 MDB-ENAO 1  SFF#0 1  VFF*OVFF® I  LLOPCeCRYFF 

•PRIORI TYLEVEL<2: 0>aNANPC<7j 0>«EXPPC)  NEXT 
ARFLT-DIVFF  OR  OVFF  NEXT 
FCHSTR«.RF26aRF279RF289RF309^D10«EXTADD  NEXT 
!NOTE  ORDER  IS  DIFFERENTTHAN  ON  230 

11s  EXTADO  set  in  FSFG  before  type  of  addreee  Is  known? 

DECODE  FCHSTR-> 

BEGIN 

#45:-  IMDB-MEMUMABI ,  (NORMAL  FETCH  (INR<31>-0) 

#41:-  MEN  1 1 MABI - 1  MOB , !  NORMAL  STORE  (INR<31>-1) 

#44:-  (IF  HSU1EN  ->IM0B-HSU19MRAR  NEXT  !CPU  FETCH  P22G.P88 
IF  HSU2EN  —  > I MDB«-HSU2  NEXTIP90 
IF  MONMSK  ->IMOB-MONNSKREG  NEXTIP87 
IF  PERMSK  ->IMDB-PERMSKREG  NEXT 
IF  INTMSK  ->IMDB-INTMSKREG), !PS8 


!ET  CETERA. 

#40;-! CPU  STORE 

(IF  HSU1EN  ->HSU1-IM0B<31:16>  NEXT 
IF  HSU2EN  ->  HSU2-IM0B  NEXT 
IF  MONMSK  - >MONMSKREG- 1  MOB  NEXT 
IF  PERMSK  - >PERMSKREG- I  MOB  NEXT 
IF  INTHSK  ->INTnSKREG-If10B), 

!ET  CETERA, 

#24:#25:-(IMAB-"F000  +  PRIORITYLEVEL  NEXT 
! "VECTOR  JUMP"-  INTVEC  ON  218. 

IMOB-MEMtIMABJ), 

!PIN  SENDS  OUT  AOORESS  OF  INTERRUPT  SERVICE  ROUTINE:  SEE  73. 
#10:  #11:  -  ( IMAB-PRJORI TYLEVELNEXT  !”JSB1"»  INTRET  ON  218. 

MEM  II MABI -1MDB) , 

!0: 1: -!JSB2 

!SPC1  IS  SAME  DECODE  VALUE  AS  JSB1 
!SPC2  IS  SAME  DECOOE  VALUE  AS  NORMAL  STORE 
#47:- 1  MOB-MEM  UMABJ  !RFI 
!RET  IS  SAME  DECODE  VALUE  AS  RFI 

ENO 

NEXT 


!  FTSC .  GENERALPURPOSEFL I PFLOPS 


P219 


PINO  NEXT 
DECODE  RF03«> 

BEGIN  IP.210 

0: -MANGPRlN-5UM<31s8>, 

1 :  -MANGPR 1  N-SUm2RS«SUt1t1RS«SUI1<31 : 1 0> , 
2: -MANGPR l N-0, 

3:  -HANGER  I  N-i  MDB<31 :  8> , 

4 :  -MANGPR I N-SUM<30: 8>*SUMMlS , 

5  s  -HANGPR 1  N-SUMMRSi3SUn<31 :  9> , 

G :  -MANGPR  i  N-SUM  <29 :  8>0SUMMLS«SUMM2LS, 
7s-NANGPR1N<-1N0B<1S:8> 

END 

NEXT 

DECODE  RFl0-> 

BEGIN 

0:-EXPGPRlN-SUM<7s0>. 
l :  -e  xrr.rn  iN-Gun<3:2>, 

2;-l:XPGPRiN-U. 

3:  -EXPOPRl M-I MDB<7s  0>, 

4  s  -EXIT.PR  I  N-SUM<Gs8><sSUMELS, 

5:  -EXPGPHIN-SUM<3s 1>, 

G:  -EXPGPR !  N-SUM<5: 0><aSUI1ELSaSUME2lS, 

7s  -EXPGPRlN-lMUB<7s0» 

END 


NEXT 

IF  RFll->  (DECODE  RF20-> 

BEGIN 

0: -MANGPR  IRA] -MANGPR IN, 

1 ;  -MANGPR  [RBI -MANGPR I N 
END)  NEXT 

IF  RF12->  (DECODE  RF20-> 

BEGIN 

0: -CXPGPR  IRA] -EXPGPRIN, 

1 : -EXPGPR  IRBI -EXPGPRIN 
END>  NEXT 

! F  TSC . UORK I NGREGI STERS  P.209 


DECODE  RF)5-> 

BEGIN 

0s-MANWniN-URYB<31s8>, 

1  s  -MANUR I  N-URYM2RSi‘9URYMRS8URYB<31  s  10> , 
2s-MANURlN-SUM<31:8>, 

3s -MANUR lN-IMDB<31s8>, 

4s -MANURIN-URYB<30: 8>*URYf1LS, 

5  s  -MANUR  I  N-URYMR$i?WRYB<3i  s  9> , 

6s  -MANURlN-URYB<29s8>0URYriLS#URYM2LSt 
7s -MANUR I N<- 1 MDB<lSs  8> 

ENO 

NEXT 
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DECODE  RF16-> 

BEGIN 

8:  -EXPURIN-URYB<7: 0>, 

1 :  -EXPUR I  N-URYB<9s 2> , 
2:-EXPURlN-SUM<7:0>, 

3 :  -EXPWR  I N*- 1  HOB <7 :  B> , 

4s  -EXPURIN-URYB<6:  0>«URYELS, 

Ss  -EXPUR 1N-URYB<8;  1>, 

G :  -EXPUR I  N-URYB<5: 0>«URYELS«UR YE2LS . 
7:-EXPURIN-IMDB<7:8> 

END 

NEXT 

IF  RF13-> 

(DECODE  RF07-> 

BEGIN 

0: -MANUR  [RF05I -MANUR IN. 

1 :  -MANUR  [RF03I  -MANUR  I N 
END)  NEXT 
IF  RF14-> 

(OECODE  RF08-> 

BEGIN 

0:  -EXPUR  [RF0GI  -EXPUR1N, 

1 :  -EXPUR  IRF04) -EXPUR  IN 
END)  NEXT 


DECODE  RF37->  ( I NTMUL-FLOMUL-0, 
( I  NTMUL-URYB<3: 2>  NEXT 
FLOMUL-URYBcll: 10>) )  NEXT 


! FTSC.  I NSTRUCT I ONREG I STERP209, 213 


IF  RFD20  ->  I  NR- 1 MOB  NEXT 
IF  RF015  -> (RA-RA  +  1  NEXT 

RB-RB  +  1)  NEXTIUHAT  HAPPENS  IF  RA  OR  RB  GETS  TOO  LARGE? 
IF  RF35  ->  RB-RB  +  1  NEXT 
TIMERO 


END! OF  REPEAT  IN  CYCLE 
END ‘OF  CYCLE 
MEND  OF  MICROFTSC 


Appendix  C 
FTSC  TARGET 


FTSC  TARGET 


NACROFTSC:-! 


tfaNemory** 

HEM  (0:3210  <31  s  0> 

**Regi  sters>v* 

COUNTER<31:0>,  ILoop  counter 


!UATCH  OUT:  THE 

GPXR{0:71 <31:0>, 

U0<31:0>. 

Ul<31:0>, 

U2<31:0>, 

U3<31:0>, 

EX<31:0>. 

rtO<3l:0>, 

NA<31:0>, 

PC<31:0>, 

EXPOUT <8 :0>, 

SUf1<31:0>, 

ALUA<33:0>, 

ALUB<33:0>, 

EXPA9<8:0>, 

EXPB9<8:0>, 


COUNTER  HERE  IS  NOT  THE  SANE  AS  IN  FTSC. NIC! 

!8  genera!  purpose  registers 
Working  register  0 
Working  register  1 
Working  register  2 
'Working  registr  3 
{Extension  register 
{Nemory  data 
{Nemory  address 
{Program  counter 
!9-bit  output  of  exponent  ALU 
!32-bit  output  of  ALU 


INTPRIOR<31:0>,  {highest  pending  interrupt  level 


INR«31:0>, 

AN0DE<2: 0>: •INR<18: 1G>, 
RA<2: 0>: •  INR<21:19>, 
RB<2:0>: »INR<2A:22>, 
OPCODE <6: 0>: -INR<31 : 25>, 
NACRO  GPXRA: - IGPXR IRA] I , 
NACRO  GPXR8 r - IGPXR [RBI  I 


Mi  S i gna I s ** 
OVFF<0>. 
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fRSCSDU»  PAGE  auiauwoi  filmed 


CRYSTS<0>, 

SUMM2<0>, 

sunm<0>, 

OVF8<0>, 

DIVFF<0>, 

CRYFF<0>, 

INVERTOR<0>. 

EXG23<0>, 

INRPT<0>, 

MON<0>, 

ASUBE<0>, 

EXMODE<0>,  (Executive  mode 

ILLOPC<0>, 

D1S1NT<0>,  {disable  interrupt 

MACRO  STATUS :  - 1  EXMODEeO  I S I  NTeO  I  VFFeOVFFel  LLOPCeCRYFFml  NTPRI  0R<2 1 0>  I 

*VfAddresg  i  ng.  Fetch  i  ng*»v 

INSTRUCTION:- 

BEGIN 

INR-MEMIPCI  NEXT 
MA<-INR<1S:0>  NEXT 
PC-PC+1 
ENO. 

AOORESS: • 

BEGIN 

OECOOE  AMODE-> 

BEGIN 

\  0:2:.NO.OP() ,  IReg-reg,  immediate,  direct 

3 « *MA*-MEM  [MA] ,  I  i  nd  i  r ec  t 

4:-(MA*-MA+GPXRA  NEXT  (Indexed,  post-increment 

GPXRA*GPXRA+1) , 

5»  •  (GPXRA*-GPXRA-1  NEXT  I  Indexed,  pre-decrement 

MA-MA+GPXRA) , 

G i .MA41A+GPXR A ,  I i ndexed 

7 1 «MA41EM (MA+GPXRA1  I  Indexed,  indirect 

ENO 

END. 


OPERAND: . 

BEGIN 

IF  NOT  INR<31>«> 

(DECODE  AM0DE» 

BEGIN 

0:«MD*GPXRA,  (This  is  slightly  different  from 
(  the  real  machine:  there  AMODE  is  checked  in  each  function  and  sometimes 
!  even  if  AMODE  ■  0,  GPXRA  does  not  have  to  go  through  MD. 

(SO  THERE'S  NO  NEED  FOR  ALL  THE  "DECODE  Afl00E"'S  IN  THE  BOOY  OF  THE  PROGRAM! 
(BUT  MAYBE  IT'S  BETTER  TO  LEAVE  THEM  IN,  AND  ELIMINATE  THE  (THEN)  EXTRANEOUS 
(DECODE  AHOOE  IN  OPERAND,  IN  ORDER  TO  MAKE  THE  AUTOMATIC  PROVING  EASIER. 


!0R  INDEED  IN  ORDER  TO  MAKE  IT  POSSIBLE:  IF  THE  MACROOESCRIPTION  SAYS 
IMO-GPXRA  BUT  IN  FACT  THAT  DOES  NOT  HAPPEN  ,  THEN  IT  CANNOT  BE  PROVED. 
!UE  COULD  INTRODUCE  ANOTHER  VARIABLE  "ARC"  TO  TAKE  THE  PLACE  OF 
I  "GPXRA  PHI  MD\ 

1: 41D-MA, 

OTHERUISE:-  MD-MEM  H1A1 
END) 

END 


VWVPrOCeSSeSfoV 


!  THE  COMPLETE  INSTRUCTION  CYCLE  IS  COOED  UNTIL  CONTROL  RETURNS  TO  I  NR  FETCH 
•  OR  "ALPHA",  DEPENDING  ON  THE  INSTRUCTION.  THIS  DIFFERENCE  UILL  HAVE 
!  TO  BE  COMPENSATED  FOR  LATER. 

LDR:- 

BEGIN 

GPXRB-MO 

END. 

LOE:- 

BEGIN 

EX-MO 

END. 

•LU0-LU3  ARE  NOT  CODED,  BUT  IF  NEEOEO  CAN  BE  CODED  LIKE  LOR  ANO  LDE. 

LOOP1 : ■ 

BEGIN 

MA-MA+1  NEXT 
DECODE  AMODE-> 

BEGIN 

0: -GPXRB-GPXRA, 

OTHERU I SE : -GPXRB-MEM  CMA] 

END 

END  , 


LDR2: - 

BEGIN 
LORO  NEXT 
RA-RA+1  NEXT 
RB-RB+l  NEXT 
LOOPIO 
END. 

L00P2:- 

BEGIN 

LOOPIO  NEXT 
RA-RA+1  NEXT 
RB-RB+1 
END, 
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LDR3: 


BEGIN 
LORO  NEXT 
RA«-RA+1  NEXT 
RB-RB+1  NEXT 
L00P2O  NEXT 
LOOPIO 
END. 

LDR7: - 

BEGIN 
LORO  NEXT 
L00P2O  NEXT 
L00P2O  NEXT 
L00P2O  NEXT 
L00P2O  NEXT 
L00P2O  NEXT 
LOOPIO 
END. 

LON:. 

BEGIN 

ALUB<32:0x-nO  NEXT 
sunm •SUM*-- ALUB  NEXT 
GPXRB-SUM  NEXT 

IF  SUMM1  XOR  SUM<31 >*>0VFF«-1  IOVERFLOU  DETECTION 
END. 


!  From  here  to  the  end  of  NORMAL  has  been  checked  with  DIVF,  Mar. 8, 78. 
!  as  OIVFML. 

NMLOOP:- 

BEGIN 

REPEAT 

BEGIN 

IF  OVF8»>  (0VFF*-1  NEXT  LEAVE  NMLOOP)  NEXT 
OECOOE  GPXRB<29«27>.> 

BEGIN 

(0, 7] i - (EXPOUT*-  (GPXRB<7>eGPXRB<7 : 0>) +-2  NEXT 

0VF8*-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB*-GPXRB<29i8>e'  00eEXPOUT<7: 0>) , 

2» Si -LEAVE  NMLOOP, 

(1 ,  GJ  i  -  (EXPOUT*-  (GPXR0<7>eGPXRB<7i  0>)  +-1  NEXT 

0VF8*€XP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXR8*-GPXRB<30i  8>e'  0eEXPOUT<7«0>  NEXT 
IF  0VF8«>0VFF*-1  NEXT 
LEAVE  NMLOOP) 

END 

ENO 
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END. 

NORMAL:-  'CALLED  IN  ADDF,  SUBF.DIVF,  LDAF.LDNF. 

!Make  sure  that  a  test  for  OVF8  is  made  at  the  end  of  above  instructions 
(before  entry  into  NORMAL. 

BEGIN 

IF  SUMMleSUM<31:8>  EQL  0->(GPXRB-H80  NEXT 

LEAVE  NORMAL)  NEXT 

DECODE  0VF8eSUMMl#SUM<31:29>-» 

BEGIN 

(010: #13) s- (EXPOUT- (GPXRB<7>eGPXRB<7s0>)+l  NEXT 

GPXRB-'  leGPXRB<31  s  9>#EXP0UT<7: 0>  NEXT 
0VF8-EXP0UT<8>  XOR  EXPOUT<7>  NEXT 
IF  0VF8->0VFF-1), 

!  THAT’S  RIGHT:  IF  BOTH  THE  PREVIOUS  EXPONENT  AND  THE  PRESENT  ONE 
I  OVERFLOU  THEN  THERE  IS  NO  GENERAL  OVERFLOU. 

[030: #33) s- (EXPOUT- (GPXRB<7>eGPXRB<7:0>)+l  NEXT 

GPXRB-’ leGPXRB<31:9>#EXPOUT<7:0>  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
IF  NOT  0VF8->0VFF-1). 

14 : 7] s - (EXPOUT- (GPXRB<7>aGPXRB<7 : 0>) +1  NEXT 

GPXRB- ' 0eGPXRB<31 s  9>eEXP0UT <7 : 0>  NEXT 
OVF 8-EXPOUT <8>  XOR  EXP0UT<7>  NEXT 
IF  0VF8->0VFF-1), 

1024 : 027] s - (EXPOUT- (GPXRB<7>eGPXRB<7s  0>) +1  NEXT 

GPXRB-’ 0#GPXRB<31 : 9>#EXPOUT<7:0>  NEXT 
OVt-8-EXPOUT<8>  XOR  EXP0UT<7>  NEXT 
IF  NOT  0VF8->0VFF-1). 

tl . 0161 s - (EXPOUT- (GPXRB<7  >*GPXRB<7 : 0>) +-1  NEXT 

0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB-GPXRB<30  : 7>eUl <31 >#EXPOUT <7 : 0>  NEXT 
!  UHAT  DOES  U1  CONTAIN  IN  ALL  THE  CASES  UHERE  NORMAL  IS  CALLED? 

!  IT  LOOKS  LIKE  IN  ALL  THE  ABOVE  CASES  Ul-0.  NOs  THERE’S  AT  LEAST 
f  ONE  CASE  FROM  ADOF  UHERE  U1  IS  NOT  ZERO. 

IF  0VF8->0VFF-1), 

(021 . 036] s - (EXPOUT- (GPXRB<7>#GPXRB<7: 0>) +-1  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB-GPXRB<30: 7>eUl<31>*EXP0UT<7s  0>  NEXT 
IF  NOT  OVF8->OVFF-1), 

(020.037,0,017] s- (EXPOUT- (GPXRB<7>eGPXRB<7:0>)+-2  NEXT 

0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB-GPXRB<29: 7>#U1<31 : 30>#EXPOUT<7: 0>  NEXT 
NMLOOPO), 

(022.023.034,0351s-  IF  0VF8->0VFF-1 , 

(2:3,014:015] s-IF  0VF8->0VFF-1 

END 

END. 

I  From  NMLOOP  to  here  has  been  checked  uith  DIVF 
LONFs- 

BEGIN 

SUMMleSUM<31:8>— (M0<31>eM0<31:8>)  NEXT 

GPXRB-SUn<31:8>oMD<7:0>  NEXT 
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Ul*-0  NEXT 
NORMAL  0 
ENO 


LOAt- 

BEGIN 
LORO  NEXT 
IF  GPXRB<31>-> 

(SUMM1«SUM*--(GPXRB<31>«GPXRB)  NEXT 
GPXRB-SUM  NEXT 

IF  SUMM1  XOR  SUM<31  >-»OVFF«-l ) 

ENO. 

LOAF i - 

BEGIN 
LORO  NEXT 
IF  GPXRB<31>-> 

(SUMM1«SUM<31 1 8>—  (GPXRB<31>«GPXRB<31  j  8>)  NEXT 
GPXRB-SUM  NEXT 
Ul-0  NEXT 
NORMAL ( ) ) 

ENO. 

LOCi- 

BEGIN 

GPXRB-NOT  MO 
END. 

LAOi- 

BEGIN 

IF  NOT  MON->LORO 
ENO. 

inoi- 

BEGIN 

IF  MON->LORO 
END. 

STRi. 

BEGIN 

OECOOE  AMOOE-> 

BEGIN 

0t -GPXRA-GPXRB, 

OTHERUISEt -MEM  [MA] -GPXRB 
ENO 

ENO. 


STEt- 

BEGIN 

OECOOE  AMOOE-> 

BEGIN 

01-GPXRA-EX, 
OTHERUISEt -MEM (MA) -EX 
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END 

END, 

ISU0-SU3  ARE  NOT  COOED  HERE,  BUT  IF  NEEOEO  THEY  ARE  LIKE  STR,  STE. 
STD:- 

BEGIN 

DECOOE  ANOOE«> 

BEGIN 

0:-  CMA<— MEM tPCJ <15: 0>  NEXT 
I  NR«-MEM  IPCJ), 

OTHERUISE:-  (MEM  IHA]  «-GPXRB  NEXT 

NEN  tNA+4096]  «-GPXRB) 

ENO 

END. 


STZ:  - 

BEGIN 

DECODE  ANODE » 

BEGIN 

0:  -GPXRA«-0, 

OTHERU I SE :  -NEN INA)  »-0 
END 

END. 

SZO:- 

BEGIN 

DECODE  ANODE -> 

BEGIN 

0s-  STD ( ) ,  !NO  STORING  OF  ZERO  IF  ANODE-0? 
OTHERUISE:-  (NEN INA] v0  NEXT 
NEN  INA+409S]  *-0) 

END 

ENO. 

STR2:- 

BEGIN 

DECODE  ANODE -> 

BEGIN 

0:-  (GPXRA«-GPXRB  NEXT 
RA-RA+1  NEXT 
RB«-RB+1  NEXT 
GPXRA-GPXRB) . 

OTHERUISE:-  (NEN [NA3 *-GPXRB  NEXT 
NA-NA+1  NEXT 
RB«-RB+1  NEXT 
NENINA]*-GPXRB) 

ENO 

END. 

STR3:- 

BEGIN 

DECOOE  ANOOE» 
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jjjggjggw; 


BEGIN 

8s-  (GPXRA*-GPXRB  NEXT 
RA«-RA+1  NEXT 
RB«-RB+1  NEXT 
STR20), 

OTHERWISE:-  (NEN IMAJ *-GPXRB  NEXT 
NA-NA+1  NEXT 
RB«-RB+1  NEXT 
STR20) 

END 

END. 


LOOPA:-  ITH1S  IS  ONLY  CALLED  UHEN  AMOOE-1 

BEGIN 
STOO  NEXT 
RA«-RA-fl  NEXT 
RB*-RB+1  NEXT 
NA*-NA+1 
END. 


ST02:- 

BEGIN 

DECODE  AMOOE-> 

BEGIN 
0s-  STOO, 

OTHERWISE:-  (LOOPAO  NEXT 
STDO) 

•END 

ENO. 


ST03s - 

BEGIN 

DECODE  Af10DE-> 

BEGIN 
0s-  STOO, 

OTHERWISE:-  (LOOPA 0  NEXT 
ST02O1 
END 

ENO. 

ST07»- 

BEGIN 

OECODE  ANODE ■> 

BEGIN 
0:-  STOO, 

OTHERWISE:-  (LOOPAO  NEXT 
LOOPAO  NEXT 
LOOPAO  NEXT 
LOOPAO  NEXT 
ST03O I 
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END. 


END 


STHs- 

BEGIN 

MEM  IMA]  *MA  SL0  IS  !? 

END. 

SPSs- 

BEGIN 

MEM  IflAJ  *-STATUSaPC<15: 0> 

•  see  p.SB  of  FTSC  Instruction  sot  document 

END. 

SPC:  - 

BEGIN 

DECODE  AM0DE-> 

BEGIN 

0:-  NO.OPO , 

OTHERU I SE :  -flEfl  CflAJ  *-MEf1  (MA+4096I  «-STATUSoPC<15 s 0> 

END 

END, 


S8PA1 : - 

BEGIN 

DECODE  ANODE -> 


?  Is-  MEN CflAJ »-GPXR0  NEXT 

I 

!NAEC<7s0>  ARE  MEMORY  ADDRESS  ERROR  CODE  BITS.  SEE  22G  LINE  G  AND  LAST 
IFOR  CONTRADICTORY  INTERPRETATIONS. 

•  END 

!  END. 

IS0PA0J. 

!  BEGIN 

!  DECODE  AMOOE»> 

!  BEGIN 

•  0:-  GPXRA-GPXRB, 

!  Is-  MEM (MAJ *-GPXRB  NEXT 

!  MAEC-0, 

!  END 

!  END, 

ISBPOls- 
!  BEGIN 

!  DECODE  AMOOE-> 

I  BEGIN 

f  0s-  GPXRA«-GPXRB, 

!  Is-  MEM  IMA]  *-GPXRB  NEXT 

!  M0EC<-1,  , 

!IMOEC<7s0>  IS  MEMORY  OATA  ERROR  CODE. 
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mi 


!  END 

I  END, 

fSBPOBt- 
!  BEGIN 

f  DECODE  ANODE ■> 

!  BEGIN 

!  0S-GPXRA-GPXRB. 

!  Is-  MEN (HA] «-GPXRB  NEXT 

!  MDEC*-0, 

!  END 

!  END, 


JMPt  - 

BEGIN 

OECOOE  AnOOE-> 

BEGIN 

0s-PC*-GPXRA, 

OTHERUISEs-PC-NA 

END 

END, 

JSB:  - 

BEGIN 

GPXRB*-STATUS®PC<15:0>  NEXT 
DECODE  ANODE -> 

BEGIN 

0:  -PC«-GPXRA, 

OTHERU I SE  s  -PC«-NA 
END 

END. 

JPZs- 

BEGIN 

IF  NOT  GPXRB<31 >-> JNP ( ) 
END. 

JNIi- 

BEGIN 

IF  GPXRB<31>->JNP() 

ENO. 

JZEi- 

BEGIN 

IF  GPXRB  EQL  0->JNP() 

END. 

JZEFt- 

BEGIN 

IF  GPXRB<31  s 8>  EQL  0->JflPO 
ENO. 
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JNZt- 

BEGIN 

IF  GPXRB  NEQ  0->JMP() 

END. 

JNZFi- 

BEGIN 

IF  GPXRB<31s8>  NEQ  0->JMP() 

END. 

JPS:  - 

BEGIN 

IF  GPXRB  NEQ  0  AND  GPXR8<31>  EQL  0->JMP() 

END. 

JPSF:  • 

BEGIN 

IF  GPXRB<31 1 8>  NEQ  0  AND  GPXRB<31>  EQL  0->JMPO 
END. 

JflZi- 

BEGIN 

IF  GPXRB<31>  EQL  1  OR  GPXRB  EQL  0  ->JNP() 

END. 

jtizfj- 

BEGIN 

IF  GPXRB<31>  EQL  1  OR  GPXRB«31:8>  EQL  0->JHP() 
END. 

JDN:  - 

BEGIN 

SUMni«SUM-(GPXRB<31>«GPXRB)  -1  NEXT 
GPXRB*-SUf1  NEXT 
IF  GPXRB  NEQ  0->jnPO 
END. 

JDS:  - 

BEGIN 

IF  OVFF->JHPU  NEXT 

OVFF-0 

END. 

XS<- 

BEG1N 

IF  CRYFF->JHPO  NEXT 

CRYFF«-0 

END. 

OISNt- 

BEGIN 

MO-NOT  flO  NEXT 
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IF  (GPXRB  OR  MO)  NEQ  #37777777777  -> 
(PC-PC+1 ) 

END, 

OlSOi- 

BEGIN 

MO-NOT  no  NEXT 

IF  (GPXRB  OR  MO)  EQL  #37777777777  -> 
(POPC+1) 

END. 

ASNZ : ■ 

BEGIN 

IF  (GPXRB  ANO  ND)  NEQ  0.>PC*-PO1 
END. 

ASZi- 

BEGIN 

IF  (GPXRB  ANO  MO)  EQL  0->POPC+l 
END. 


ICSNE  AND  CSEQ  ARE  NOT  ON  THE  FLOUCHART  DIAGRAMS 
AOOt- 

BEGIN 

SUMM2®SUMM1  ®SUM*-GPXRB  <31 >®GPXRB  +  MD<31>®MD  NEXT 
IF  SUMM2 - >CR YFF «-l  NEXT 
GPXRB*-SUM  NEXT 

if  (sunm  xor  sum<31>)->ovff«-i 
END, 

SUB*  ■ 

BEGIN 

sunn2®sunni®sun^GPXRB<3i>«GPXRB  +  -(M0<31>®md)  next 

IF  SUMn2->CRYFF*-l  NEXT 
GPXRB-SUn  NEXT 

if  (sunm  xor  sum<31>)->ovff.-i 

END, 

IPY:- 

BEGIN 

EX-GPXRB  NEXT 
GPXRB«-0  NEXT 
COUNTERS  NEXT 
CRYSTS-0  NEXT 
L00P5;- 

REPEAT 

BEGIN 

ALUA< -GPXRB  NEXT  IIT  APPEARS  THAT  UE  NEED  GPXRB  ANO  MO  SIGN 
I  EXTENDED  TUO  BITS,  SO  HERE  ALUA  AND 
!  ALUB  SHOULD  BE  34  BITS. 


DECOOE  CRYSTSaEX<ls0>-> 

BEGIN 

0:-  ( SUMM2aSUMM  1 aSUM-ALUA  NEXT 
CRYSTS-0), 

Is-  ( sunf12asurin  1  aSUM-ALUA+ALUB  NEXT 
CRYSTS-0) , 

2s-  (SUMM2aSUMMlaSUM-ALUA-  (ALUB  SL0  1)  NEXT 
CRYSTS*-1 ) 

3s-  (SUMM2aSUMM  1  aSUM-ALUA-ALUB  NEXT 
CRYSTS-1 ) 

4s-  (SUnn2aSUtiniaSUf1«-ALUA+ALUB  NEXT 
CRYSTS-0) , 

5s-  (SUMM2aSUMMleSUM-ALUA+(ALUB  SL0  1)  NEXT 
CRYSTS-0) 

Bs-  (SUMM2aSUMMl aSUM-ALUA-ALUB  NEXT 
CRYSTS-1 ) 

7s-  ( SUMM2aSUMM  1  aSUM-ALUA  NEXT 
CRYSTS-1) 

END  NEXT 

GPXRB-SUMM2eSUMMl8SUM<31s2>  NEXT 
EX-SUf1<l  s  0>eEX<31  s  2>  NEXT 
COUNTER-COUNTER+1  NEXT 
IF  COUNTER  EQL  1G->LEAVE  L00P5 
END  NEXT 

!At  thi 9  point  in  the  computation,  the  9ign  appears  in  GPXRB<31s30> 
land  the  msb’s  to  lsb'9  are  in  GPXRB<29s0>aEX. 

EX-EX<30s  0>aGPXRB<31>  NEXT 
GPXRB-GPXRB<30s  0>aEX<31>  NEXT 

U0-GPXRB  NEXT  MS  THIS  NEEDED  FOR  SOMETHING?  FDR  EXAMPLE 
! IF  MPY  IS  EXITED  ON  OVFF. 

IF  GPXRB<31>  XOR  GPXRB<30>-> (OVFF-1  NEXT  LEAVE  MPY)  NEXT 

GPXRB-EX  SRR  1  NEXT  !EX  ROTATED  RIGHT  ONE  BIT 

EX-U0 

END, 

PPLOOPs - 

BEGIN 

REPEAT 

BEGIN 

COUNTER-COUNTER+1  NEXT 

DECODE  I NVERT0R-> (SUM-GPXRB-MD, SUM-GPXRB+MD)  NEXT 

GPXRB-SUM<30s  0>aEX<31>  NEXT 

EX-EX<30s0>aNOT  INVERTOR  NEXT 

INVER  TOR -SUM  <  3 1 >  NEXT 

IF  COUNTER  EQL  30->LEAVE  PPLOOP 

END 

END, 


PMLOOPs - 

BEGIN 

REPEAT 

BEGIN 
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COUNTER-COUNTER+1  NEXT 

DECODE  INVER  TOR.  >  (SUM-GPXRB+MO. SUM-GPXRB-MD)  NEXT 

GPXRB-SUM<30:8>®EX<31>  NEXT 

EX-EX<30: 0>al NVERTOR  NEXT 

INVERTOR-SUM<31>  NEXT 

IF  COUNTER  EQL  29->  LEAVE  PMLOOP 

END 

END, 


DIVPPs. 

BEGIN 

EX-EX  SL0  1  NEXT 

SUM-GPXRB-MO  NEXT  !IN  01 V  GPXRB-0  HERE. 

IF  NOT  SUf1<31  >■> (01 VFF-1  NEXT  LEAVE  DIVPP)  NEXT  IOENOM-0  IN  DIV 
•AND  MSB  HALF  OF  NUMERATOR  GEO  DENOMINATOR  IN  LDV 
GPXRB«-SUM<30: 0>aEX<31>  NEXT 
EX-EX  SL0  1  NEXT 
INVERTOR-1  NEXT 
COUNTER-0  NEXT 
PPLOOPO  NEXT 

DECODE  I NVERTOR-> (SUM-GPXRB-MO, SUM-GPXRB+MD)  NEXT 
GPXRB-SUM  NEXT 

EX-EX<30:0>®NOT  INVERTOR  NEXT 
DECODE  GPXRB<31>-> 

BEGIN 

0:-  (U0-GPXR8  NEXT 

GPXR0-IEX  SL0  1)  +1  NEXT 
EX-U0) , 

It-  (U0-GPXR8  +  MO  NEXT 

GPXRB-EX  SL0  1  NEXT 
EX-U0) 

END 

END, 


OIVPMs- 

BEGIN 

•THE  STEP  EX-EX  SL0  1  IS  TAKEN  CARE  OF  A  FEU  LINES  HENCE.  , 
SUM-GPXRB+MD  NEXT  ! IN  DIV  GPXRB-0  HERE. 

IF  SUM  GTR  0-> (01 VFF-1  NEXT  LEAVE  DIVPM)  NEXT 

•THIS  IS  IMPOSSIBLE  FOR  DIV.  FOR  LDV  THIS  CHECKS  IF  MS  HALF 

•OF  NUM  GTR  ABSOLUTE  VALUE  OF  DENOMINATOR. 

IF  (SUM  EQL  0)  AND  (U0  NEQ  0)->(OIVFF-l  NEXT  LEAVE  OIVPM)  NEXT 
•THIS  IS  ALSO  IMPOSSIBLE  FOR  DIV.  IN  LDV  IT  CHECKS  IF  MS  HALF 
I  OF  NUMERATOR  EQL  ABSOLUTE  VALUE  OF  DENOMINATOR  AND  LS  HALF 
•OF  NUMERATOR  NEQ  0. 

GPXR8-SUM<30: 0>aEX<30>  NEXT 
EX-EX<29j0>®’01  NEXT 

IF  SUM  EQL  0-> INVERTOR-0  NEXT  I AT  THIS  POINT  LS  HALF  OF 
!NUM  IN  LDV  IS  KNOUN  TO  BE  ZERO. 

IF  SUM  LSS  8->t 
SUM-GPXRB-MO  NEXT 
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GPXRB-SUH<30: 0>«EX<3i>  NEXT 
EX-EX  SL1  1  NEXT 
I NVERT0R-SUM<31 > '  NEXT 
COUNTER-0  NEXT 
PMLOOPO  NEXT 

OECOOE  I NVERTOR- > (GPXRB-GPXRB+MD, GPXRB-GPXRB-MD)  NEXT 

EX-EX<30: 0>®1NVERTOR  NEXT 

OECOOE  GPXRB<31>»>  ( (U0-GPXRB  NEXT  EX-EX  SL0  1), 

(U0-GPXRB-MO  NEXT  EX-EX  SL1  1))  NEXT 

GPXRB-EX+1  NEXT 

EX-U0 

END, 


OlVtlPj- 

BEGIN 

EX-EX  SL0  1  NEXT 

GPXRB-GPXRB+MD  NEXT  'HERE  IN  DIV  GPXRB-MD-1. 

IF  GPXRB<31>-> (01 VFF-1  NEXT  LEAVE  DIVMP)  NEXT  ! CHECK  FOR  OENOM-0 
ACTUALLY  UE  MAY  have  TO  EXECUTE  ALSO  GAB  IN  ORDER  THAT  THE  PROPER 
I  VALUES  BE  IN  GPXRB  AND  EX  UHEN  CONTROL  GETS  THE  INTERRUPT  SIGNAL. 
GPXRB-GPXRB<30:0>*EX<31>  NEXT 
EX-EX  SL1  1  NEXT 
SUM-GPXRB-MO  NEXT 
INVERT0R-SUf1<31>  NEXT 
GPXRB-SUM<30: 0>«EX<31>  NEXT 
EX-EX  SL1  1  NEXT 

PPLOOP ( )  NEXT  (SAME  LOOP  AS  FOR  +/+ 

DECODE  I NVERTOR-> (SUM-GPXRB-MO, SUM-GPXRB+MD)  NEXT 
GPXRB-SUfl  NEXT 

EX-EX<30: 0>®NOT  INVERTOR  NEXT 
IF  GPXRB  GTR  0-> (UO-GPXRB-Ttt)  NEXT  IE.G.-A/5 
EX-EX  SL1  1  NEXT 
GPXRB-EX  +  1  NEXT 
EX-U0  NEXT 
LEAVE  OIVttP)  NEXT 

IF  GPXRB  EQL  0-> (GPXRB- (EX  SL0  1)  +  1  NEXT  IE.G.-4/4 
EX-0  NEXT  LEAVE  DIVMP)  NEXT 
IF  GPXRB  LSS  0-> (GPXRB-GPXRB+MD  NEXT 

IF  GPXRB  EQL  0-> (GPXRB-EX  SL0  1  NEXT  IE. G. -4/2 
EX-0  NEXT  LEAVE  DIVMP)  NEXT 
IF  GPXRB  NEQ  0»> (U0-GPXRB-MD  NEXT  IE.G.-4/3 
EX-EX  SL0  1  NEXT 
GPXRB-EX  +  1  NEXT 
EX-U0) ) 

END, 


OIVMMt- 

BEGIN 

EX-EX  SL0  1  NEXT 

SUM-GPXRB-MO  NEXT  UN  DIV  GPXRB— 1  HERE. 

IF  SUM  LSS  0«> (01 VFF-1  NEXT  LEAVE  01  VMM)  NEXT 

(THIS  IS  IMPOSSIBLE  FOR  DIV.  IN  LDV  THIS  CHECKS  IF  MD  GTR  GPXRB 
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! I .E. ,  IF  ABS. VALUE  OF  MS  HALF  OF  NUMERATOR  GTR  ABS.  VALUE  OF 
•DENOMINATOR. 

GPXRB-SUM<30: 0>»EX<31>  NEXT 
EX-EX  SL0  1  NEXT 

IF  (SUM  EQL  0)  AND  (EX  EQL  0)->(OIVFF-l  NEXT  LEAVE  DIVMM)  NEXT 
•SO  ‘1X0...0/-1  Y1ELOS  OIVFF  IN  D1V  SINCE  SUM  EQL  0<->  TO— 1  IN  OIV. 
•IN  LOV  THIS  CHECKS  IF  MS  HALF  OF  NUM  -  DENOMINATOR  ANO  LS  HALF  - 
!’1X0...0  AS  IN  DIV.  AGAIN  THIS  DOES  NOT  MAKE  SENSE. 

COUNTER-0  NEXT 
INVERTOR-0  NEXT 

PMLOOPO  NEXT  ISAME  LOOP  AS  +/-. 

DECODE  !NVERTOR->(GPXRB-GPXRB+MD,GPXRB-GPXRB-MD)  NEXT 
EX-EX<30:0>«INVERTOR  NEXT 

IF  GPXRB  EQL  0->(GPXRB-(EX  SL0  1)  +1  NEXT  IE.G.-4/-4 
EX-0  NEXT  LEAVE  DIVMM)  NEXT 
IF  GPXRB  GTR  0->(U0-GPXRB+MD  NEXT  IE.G.-4/-S 
GPXRB-EX  SL0  1  NEXT 
EX-U0  NEXT  LEAVE  DIVMM)  NEXT 
IF  GPXRB  LSS  0-> (U0-GPXRB-MO  NEXT 

IF  U0  EQL  0-> (EX-EX  SL1  1  NEXT  IE.G.-4/-2 
GPXRB-EX  +  1  NEXT 
EX-0  NEXT  LEAVE  DIVMM)  NEXT 
IF  U0  NEQ  0-> (U0-GPXRB+MD  NEXT  IE.G.-4/-3 
EX-EX  SL0  1  NEXT 
GPXRB-EX+1  NEXT 
EX-U0) ) 

END. 


•GPXRB  CONTAINS  NUMERATOR  ANO  MD  DENOMINATOR.  QUOTIENT  GOES  IN 
GPXRB  UITH  REMAINDER  IN  EX.  SIGN  OF  REMAINDER  IS  SAME  AS 
SIGN  OF  NUMERATOR. 

BEGIN 

EX-GPXRB  NEXT 

DECODE  GPXRB<31 >®MD<31 >-> 

BEGIN 

0-.-(GPXRB-0  NEXT  DIVPPO),  !+/+ 

1 : •  (GPXRB-0  NEXT  OJVPMO),  !+/- 
2:  -  (GPXRB— 1  NEXT  DIVMPO).  !-/♦ 

3:  *  (GPXRB— 1  NEXT  DIVMMO)  !-/- 
END 

END. 


LDVj-  • NUMERATOR  IS  EX«GPXRB,  DENOMINATOR  IS  MD.  (PROBABLY)  EX<31>-GPXRB<31>. 
•OTHER  DETAILS  AS  IN  OIV. 

•  (AT  THE  START  EX  AND  GPXRB  ARE  INTERCHANGED) 

BEGIN 

U0-GPXRB  NEXT 
GPXRB-EX  NEXT 
EX-U0  NEXT 
U0-EX  SL0  1  NEXT 

IF  (GPXRB  GEQ  0)  ANO  (MO  GEQ  0)->(OIVPP()  NEXT  LEAVE  LOV)  NEXT 


DIVI :  ■ 
« 

I 
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IF  (GPXRB  GEQ  0)  AND  (M0  LSS  0)->(DIVPM()  NEXT  LEAVE  LDV)  NEXT 

IF  (GPXRB  LSS  0)  AND  (MD  GEQ  0)->(DlVMP()  NEXT  LEAVE  LDV)  NEXT 

IF  (GPXRB  LSS  0)  ANO  (MO  LSS  0)->(DIVMM()  NEXT  LEAVE  LDV) 

END. 

ACOs- 

BEGIN 

SUMM29SUMM1#SUM^  (GPXRB<31  >«GPXRB)  +  (MD<31>«MO)  +CRYFF  NEXT 

GPXRB*-SUM  NEXT 

IF  SUMM2->CRYFF«-1  NEXT 

IF  SUMM1  XOR  SUM<31  >«>OVFF*-l 

ENO, 

LOOPS*. 

BEGIN 

REPEAT 

BEGIN 

CPXRB-GPXRB  SL0  2  NEXT 
Ul-Ul-2  NEXT 

IF  NOT ((GPXRB  NEQ  0  AND  GPXRB<31i29>  EQL  0)  OR 
(GPXRB  <3i:29>  EQL  7))->  LEAVE  LOOPS 
ENO 

END. 


CFL:-  (TAXES  GPXRA  OR  MD  INTEGER  AND  CONVERTS  TO  FLOATING  IN  GPXRB. 

!  THE  MANTISSA  IS  INTERPRETED  AS  A  BINARY  FRACTION  LESS  THAN  1. 

BEGIN 

GPXRS-MO  NEXT 
Ul-0  NEXT 

IF  (GPXRB  NEQ  0)  ANO  (GPXRB<3I:29>  EQL  0  OR  GPXRB<31i29>  EQL  7)-> 

LOOPS  0  NEXT 

(LOOPS  CAN  CHANGE  THE  VALUE  OF  HI. 

IF  GPXRB  EQL  0->(GPXRB-"80  NEXT  LEAVE  CFL)  NEXT 
IF  GPXRB<3I>  XOR  GPXRB<30>-> 

(ALREADY  NORMALIZED 

(GPXRB<7:0>«-U1<7!0>  NEXT  GPXRB<7:0>«£PXRB<7*0>+31  NEXT  LEAVE  CFL)  NEXT 
IF  (GPXRB<31:29>  EQL  8)  OR  (GPXRB<31i29>  EQL  1)  -> 

(NORMALIZE  FIRST 

(GPXRBfcGPXRB  SL0  1  NEXT  GPXRB<7!0>441-1  NEXT 

GPXRB<7i  0>«-GPXRB<7*  0>+31 ) 

ENO. 


ADDLPlt- 

BEGIN 

REPEAT 

BEGIN 

GPXRB<31i8>*-GPXRB<31>9GPXRB<31>«GPXRB<3l!l0>  NEXT  !? 
U1 <7 s  0>*-Ul  <7 : 0>+2  NEXT 
GPXRB<7 j  0>»-MO<7*  0>  NEXT  , 

IF  Ul<7:0>  EQL  0->LEAVE  AOOLP1 
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AD0LP2» 


BEGIN 

REPEAT 

BEGIN 

Ul<7s8>*4Jl<7«0>-2  NEXT 

MD<31  s  8>«-li0<31  >»M0<31  >«MPi31  *  10>  NEXT 

IF  Ul<7:0>  EQL  0->LEAVE  A00LP2 

END 

END. 


AOOFs- 

BEGIN 

f FIRST  COMPARE  THE  TUO  EXPONENTS.  THEIR  DIFFERENCE  GOES  IN  EXPOUT. 


EXPOUT*-GPXRB<7>«GPXR0<7: 0>-MD<7>»MD<7: 0>  NEXT 
U1  <7: 0>*-SUM<7s  0>*-EXPOUT <7s  0>  NEXT 
‘  UHAT  DO  UE  NEED  U1  FOR? 

IF  SUM<7:0>  EQL  0->(DECOOE  ASUBE-> (GPXRB<31 : 8>^GPXRB<31 : 8>+M0c31  s 8> , 

GPXRB<31 1 8>*-GPXRB*31 :  8>-MD<31  s  8>)  NEXT 
U1*0  NEXT  NORMAL!)  NEXT  LEAVE  ADOF)  NEXT 
!  SO  FROM  HERE  ON  SUM<7s0>  NEQ  0. 

0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 

EXG23*- (EXPOUT <7 ; 0>  GTR  23)  OR  (EXPOUT<7:0>  LSS  -23)  NEXT 
DECODE  EXG23@OVF8«SUM<0>*SUM<7>-> 

BEGIN 

(4j7,014;017]i-((IF  GPXRB<7>->  ! IF  GPXRB  EXPONENT  <0 
(DECODE  ASUBE->(GPXRB*flD. 

GPXRB*-  ( -MD<31 :  8> )  «MD<7 1 0> ) ) )  NEXT 
LEAVE  ADDF), 

[011,013] :■ (DECODE  ASUBE->(GPXRB-MO, 

GPXRB*-  ( -MD<3 1 1 8> )  «MD<7 :  8>)  NEXT 
LEAVE  ADDF), 

[010,01211 -LEAVE  ADDF, 

It-  ADDLP10, 


3:-  (GPXRB<31»8>*-GPXRB<31>«GPXRB<31t9>  NEXT 
U1<7;0>*-U1<7:0>+1  NEXT 
GPXRB<7i0>*MD<7»0>  NEXT 
ADOLPIO), 

0j-  A0DLP2O. 

2»-(  Ul<7t  0>*-Ul <7 j  0>-l  NEXT 

f1D<31 1 8>*-M0<31  >«MO<31 1 9>  NEXT 
ADDLP20) 


ENO  NEXT 


ALUAc-GPXRB  NEXT  (SIGN  EXTEND  ONE  BIT 
ALUB<-ttO  NEXT 
DECODE  ASUBE-> 

BEGIN 

0:  -SUnf12®SUf1Hl9GPXRB<31 :  8>«- 

GPXRB<31  >»GPXRB<31 :  8>+HD<31  >«MD<31  s  8> , 
1  s  -SUnf12®SUrim®GPXRB<31  :  8>*- 

GPXRB<31 >*GPXRB<31 : 8>-J1D<31 >*H0<31 : 8> 
END  NEXT 

IF  SUnt12->CRYFF-l 

END, 


SUBFj - 

BEGIN 

ASUBE-l  NEXT  IAUTO  SUBTRACT  ENABLE 

ADDFO 

END. 


!From  hero  to  the  end  of  MPYF  has  been  checked  in  MPYFML 


! Vers  ion  of  Mar. 3, 1978 
fllNUSli  ■ 

BEGIN 

GPXRB<31 : 8>-GPXRB<30i 8>*EX<31>  NEXT 
EX-EX  SL0  1  NEXT 
EXPA9<-GPXRB<7i0>  NEXT 
EXP0UT-EXPA9-1  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB<7  s  0>*-EXPOUT  <7 1 0> 

END. 

MINUS2J- 

BEGIN 

GPXRB<31 : 8>-GPXRB<29:8>*EX<31 : 30>  NEXT 
EX-EX  SL0  2  NEXT 
EXPA9<-GPXRB<7»0>  NEXT 
EXP0UT-EXPA9-2  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB<7 :  0>«-EXPOUT  <7i  0> 

END, 


nPYFlAi- 

BEGIN 

niOOPl:- 

REPEAT 
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MPYFIBj 


flPYFi  • 


BEGIN 

IF  (0VF8aGPXRB<31 « 29>  NEQ  0  AND 
0VF8aGPXRB<31:29>  NEQ  7)-> 
LEAVE  HL00P1  NEXT 
M1NUS20 

END  !Of  MLOOP1 
NEXT 

IF  (0VF8aGPXRB<31 t 29>  EQL  B  OR 
OVF8aGPXRB<31:29>  EQL  l)-> 
MJNUSIO  NEXT 
EX<31 :  8>«-’  0aEX<31 :  9>  NEXT 
IF  0VF8«>0VFF*.l 

END, 


m 

BEGIN 

REPEAT 

BEGIN 

DECODE  0VF8aGPXRB<3l!29>.> 

BEGIN 

tl.Glj-fllNUSlO, 

10,7]  :«M1NUS20 , 

W11,#1S]:-(MINUS1()  NEXT 

EX<31 :8>«-’  0@EX<31 :  9>  NEXT 
IF  OVF8->OVFF-l  NEXT  LEAVE  MPYFIB) , 

[2:5J :  •(OVFF*-l  NEXT  LEAVE  MPYFIB) , 
t»12:#15):-(EX<31:8>^’09EX<31:9>  NEXT  LEAVE  MPYFIB), 
MU0,#17J:.(MINUS2()  NEXT 

MPYF1AO  NEXT  LEAVE  MPYFIB) 

ENO  ! of  decode 

ENO  loREPEAT 

ENO.  !of  MPYFIB 


I  TAKES  NORMALIZED  GPXRB  AND  MD  (OR  GPXRA)  IN  FLOATING  POINT 
(FORM  AND  PUTS  THE  SIGN  OF  THE  PRODUCT  AND  23  MSB’S  IN 
•MANTISSA  OF  GPXRB,  23  LSB’S  IN  BITS  <30: 8>  OF  EXTENSION 
(REGISTER,  AND  EXPONENT  IN  EXPONENT  OF  GPXRB. 


BEGIN 

EX*-GPXRB<31 :  8>a'  00000000  NEXT 
GPXRB<31»8>-0  NEXT 

IF  NOT  AMODE->(MD*GPXRA)  NEXT  IOTHERUISE  USE  OLD  MD 
COUNTERS  NEXT 
CRYSTS-0  NEXT 
LOOPSFj- 


REPEAT 

BEGIN 

ALUA<33:8x-GPXRB<31:8>  NEXT  (HERE  ALSO  (AS  IN  MPY  INTEGER) 

ISIGN-EXTEND  TUO  BITS) 

ALUB<33: 8><«MO<31 : 8>  NEXT 
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DECODE  CRYSTSaEX<9:8>-> 

BEGIN 

0:-  (SUf1t12aSUI1f11aSUf1<31  s  8>-ALUA<33s  8>  NEXT 
CRYSTS*-0) 

Is-  (SUfin2aSUnnUSUH<31  s 8>-ALUA<33: 8>+ALUB<33: 8>  NEXT 
CRYSTS*-0) 

2:-  (SUMH2aSUtiril*kjH<31»8>- 

ALUA<33:8>- CALUB<33t 8>  SL0  1)  NEXT 
CRYSTS-1), 

3s-  (SUMf12aSUnt11aSUM<31  s 8>-ALUA<33: 8>-ALUB<33s  8>  NEXT 
CRYSTS-1) , 

As-  (SUMM2aSUf1MlaSUtt<31 : 8>-ALUA<33s  8>+ALUB<33s  8>  NEXT 
CRYSTS«-0) 

5s  -  ( SUf1f12aSUMf1 1  aSUM<31  s 8>- 

ALUA<33:8>+(ALUB<33:8>  SL0  1)  NEXT 
CRYSTS-0) , 

Gs-  (SUMM2aSUHf11aSUM<31s8>«-ALUA<33s8>-ALUB<33:8>  NEXT 
CRYSTS-1), 

7s-  (SUm2aSUIt1l9SUt1<31s8>^ALUA<33s8>  NEXT 
CRYSTS-1) 

ENO  NEXT 

GPXRB<31 : 8>-SUMn2aSUnHlaSUn<31 ;  10>  NEXT 
EX<31 : 8>-SUn<9: 8>aEX<31  s  10>  NEXT 
COUNTER-COUNTER+1  NEXT 
IF  COUNTER  EQL  12->LEAVE  L00P5F 
ENO  NEXT 

IF  GPXRB<31:8>  EQL  0-> <GPXRB-"80  NEXT  EX-0  NEXT  LEAVE  MPYF)  NEXT 
!  THAT  IS  THE  FLOATING  REPRESENTATION  OF  ZERO. 

•Eliminate  GPSDECODE  GPSDECODEO  NEXT  LEAVE  MPYF)  NEXT 

EXPA9<-GPXRB<7s0>  NEXT  IHERE  UE  ARE  USING  THE  MICROHACHINE  NOTATION. 

EXPB9<-nO<7:0>  NEXT 

EXPOUT -EXPA9+EXPB9  NEXT 

GPXRB<7 s  0>-EXPOUT <7 : 0>  NEXT 

0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 

DECODE  GPXRB<31s29>-> 

BEGIN 

[0,71s- (GPXRB<31: 8>-GPXRB<29s  8>aEX<31 s  30>  NEXT 
EX-EX  SL0  2  NEXT 
DECODE  OVF8-> 

!Ue  do  the  decode  on  0VF8  here  ,  even  though  the  first  A  lines 
!in  both  cases  are  the  same,  because  0VF8  is  recalculated  immediately 
land, I  didn’t  see  any  other  uay  that  would  not  introduce  fictitious 
Iregisters  or  something  I  ike  the  DELAY. 

BEGIN 

0s-  (EXPA9<-GPXRB<7$0>  NEXT 
EXP0UT-EXPA9-1  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB<7 : 0>-EXPOUT <7 s  0>  NEXT 
MPYF1AO ) , 

Is-  (EXPA9<-GPXRB<7t0>  NEXT 
EXP0UT-EXPA9-1  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  NEXT 
GPXRB«7  s  0>-EXPOUT  <7  s  0>  NEXT 
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******** 


MPYF1B0) 

END) , 

tl,G)  i-  (GPXRB<31  s 8>»-GPXRB<30j  8>eEX<31>  NEXT 
EX-EX  SL0  1  NEXT 
EX<31  s  8>«-’  0#EX<31 1 9>  NEXT 
IF  0VF8»>0VFF*-1) , 

2f  (DECODE  0VF8-> 

BEGIN 

0:-(EXPA9<-GPXRB<7i0>  NEXT 
EXP0UT-EXPA9+1  NEXT 
0VF8*-EXP0UT<8>  XOR  EXPOUT<7>  NEXT 
GPXRB<7 s  0>*-EXPOUT <7 1 0>  NEXT 
EX<31 1 8>«-'  0eEX<31 1 9>  NEXT 
IF  0VF8->0VFF*-1), 
lt-(EXPA9<-GPXRB<7t0>  NEXT 
EXP0UT-EXPA9+1  NEXT 
0VF8«-EXP0UT<8>  XOR  EXPOUT<7>  NEXT 
GPXRB<7  s  0>*-EXPOUT <7 » 0>  NEXT 
EX<31:8>-*0sEX<31i9>  NEXT 
IF  NOT  OVF8»OVFF*-l)  (here's  the  difference 


END) 

END 

IUHY  ARE  3  AND  5  IMPOSSIBLE?  Because  GPXRB<31:30>  contains 
(the  sign  bit  repeated.  2  is  on  I g  possible  for  -2T23x-2t23. 

END. 


!  From  the  last  landmark  to  here  has  besn  checked  as  MPYFML 


f  From  here  to  the  end  of  DIVF  has  been  checked  along  with  NORMAL, Mar. 8, 78 
!  as  DIVFML. 

FPPLOOPi - 

BEGIN 

REPEAT 

BEGIN 

C0UNTER-C0UNTER+1  NEXT 

DECODE  INVERT0R->  (SUM<31 1 8>-GPXRB<31 1 8>-M0<31 :  8>, 

SUM<31 1 8>*-GPXRB<31  ( 8>+M0<31 1 8>)  NEXT 
EX<31 s 8>«-EX<30: 8>eN0T  INVERTOR  NEXT 
INVERT0R«-SUM<31>  NEXT 

IF  COUNTER  EQL  23->  LEAVE  FPPLOOP  NEXT 
GPXRB<31 :  8>«-SUM<30 :  8>eEX<31  > 

ENO 

END. 
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FPMLOOP: - 

BEGIN 

REPEAT 

BEGIN 

CQUNTER-COUNTER+1  NEXT 

DECOOE  I NVERTOR->  (SUf1<31  s  8>-GPXRB<31  s  8>+MD<31 :  8> , 

SUM<31 :  8>-GPXRB<31  s  8>-MD<31 :  8>)  NEXT 
EX<31:8>-EX<30:8>»  INVERTOR  NEXT 
I  NVERTOR-SUM<31  >  NEXT 
IF  COUNTER  EQL  23->  LEAVE  FPMLOOP  NEXT 
GPXRB<31:8>-SUM<30:8>*EX<31> 

END 

END. 

01 VF: ■  IGPXRB/MO 

BEGIN 

IF  NOT  AMOOE->MD-GPXRA  NEXT 
Ul<7: 0>-"FF  NEXT  !?? 

EX<31>-GPXRB<8>  NEXT 

GPXRB<31 : 8>-GPXRB<31 >®GPXRB<31 : 9>  NEXT 

IF  MO  EQL  0-><OIVFF-l  NEXT  LEAVE  DIVF)  NEXT 

DECOOE  GPXRB<31 >®M0<31 >•> 

BEGIN 

0:- (COUNTERS  NEXT 

SUM<31 : 8>-GPXRB<31 : 8>-M0<31 : 8>  NEXT 
GPXRB<31 : 8>-SUM<30: 8>®EX<31 >  NEXT 
EX<31  : 8>-EX<30: 8>®' 0  NEXT 
INVERT0R-SUM<31>  NEXT 
FPPLOOPU  NEXT 
GPXRB<31:8>-SUM<31:8>  NEXT 
Ul<31:8>-0  NEXT  IFOR  USE  IN  NORMAL!)  ?? 

DECODE  GPXRB<31>»> 

BEGIN 

0i  ■  (H0<31 : 8>-GPXRB<31 : 8>  NEXT 

GPXRB<31:8>-EX<31:8>  SL0  1  +  1  NEXT 
EX<31:8>-140<30:8>®’  1) ,  I? 

1 : - (U0<31 x 8>-GPXRB<31 :  8>+MD<31 x 8>  NEXT 
GPXRB<31 : 8>-EX<31 :  8>  SL0  1  NEXT 
EX<31:8>-U0  SL0  1) 

END), 

It -(COUNTER-0  NEXT 

SUM<31 : 8>-GPXRB<31 s  8>+MD<31 1 8>  NEXT 

GPXRB<31 j  8>-SUM<30: 8>#EX<31 >  NEXT 

EX<31 s  8>-EX<30i 8>®’ 1  NEXT 

INVERT0R-SUM<31>  NEXT 

FPMLOOP ( )  NEXT 

GPXRB<31 : 8>-SUM<31 i 8>  NEXT 

Ul<31:8>-0  NEXT 

DECODE  GPXRB<31>» 

BEGIN 

0t - (U0<31 1 8>-GPXRB<31 1 8>  NEXT 
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GPXRB<31s8>-EX<31s8>  SL0  1+1  NEXT 
EX<31:8>«-140<30:8>®’  1) , !? 

1 s - (U0<31 s 8>-GPXRB<31 :  8>-MD<31 : 8>  NEXT 

GPXRB<31s8>-EX<31:8>  SL 11+1  NEXT 
EX<31 :  8>-U0<30s 8>a*  1 )  !? 

END), 


2s -(COUNTER-0  NEXT 

SUM<31 :  8>-GPXRB<31  s  8>+f1D<31  s  8>  NEXT 

GPXRB<31 : 8>-SUM<30: 8>®EX<31>  NEXT 

EX<31 :  8>-EX<30: 8>a*  1  NEXT 

INVERT OR-SUfl < 3 1 >  NEXT 

FPPLOOPO  NEXT 

GPXRB<31 : 8>-SUM<31 s  8>  NEXT 

Ul<31:8>-0  NEXT 

DECODE  GPXRB<31>-> 

BEGIN 

0i - (U0<31 s  8>-GPXRB<31 s  8>-MD<31 : 8>  NEXT 

GPXRB<31 s  8>-EX<31 ; 8>  SL1  1  +1  NEXT 
EX<31s8>-U0<30s8>a*l) ,  !? 

1  s  -  (GPXRB<31  s  8>-EX<31 :  8>  SL0  1+1  NEXT 
EX<31s8>-U0<30s8>a,l)  !? 

END), 

3s -(COUNTER-0  NEXT 

SUH<31 s  8>-GPXRB<31 s  8>-MD<31 s  8>  NEXT 
GPXRB<31 s  8>-SUM<30s  8>«EX<31>  NEXT 
EX<31 s  8>-EX<30s  8>a’ 0  NEXT 
INVERT0R-SUN<31>  NEXT 
FPfILOOPO  NEXT 
GPXRB<31 : 8>-SUM<31 s  8>  NEXT 
Ul<31s8>-0  NEXT 
OECOOE  GPXRB<31>-> 

BEGIN 

0s  - (U0<31 : 8>-GPXRB<31 s 8>+MD<31 : 8>  NEXT 
GPXRB<31 : 8>-EX<31 s  8>  SL0  1  NEXT 
EX<31 s  8>-U0<31 : 8>  SL0  1), 

1 s - (GPXRB<31 s  8>-EX<31 s  8>  SL0  1  +1  NEXT 
EX<31 s  8>-U0<30: 8>a* 1 )  !? 

END) 


SUttm®SUf1<31  J  8>-GPXRB<31  >®GPXRB<31  s  8>  + 

GPXRB<31 >aGPXRB<31 s  8>  NEXT 
GPXRB<31  s  8>-SU)1<31  s  8>  NEXT 
EXPOUT-GPXRB<7>«GPXRB<7s0>  -  MD<7>af1D<7s0>  NEXT 
0VF8-EXP0UT<8>  XOR  EXP0UT<7>  fjEXT 
GPXRB<7 s  0>-EXPOUT <7 : 0>  NEXT 
NORflALO 


IFpobi  FPPLOOP  to  haro  has  baan  chackad  along  with  NORMAL. 
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•From  here  to  the  end  of  SRTF  has  been  checked  as  SQRTML 

SRTF:-  ! TAKES  FLOATING  GPXRA  OR  HD  AND  PUTS  SQUARE  ROOT  IN  GPXRB. 

!A  •  m  x  2te.  (t  indicates  exponentiation) 

BEGIN 

IF  NOT  Af100E-> (MD-GPXRA)  NEXT 

IF  NO  LSS  0-> (OVFF-1  NEXT  LEAVE  SRTF)  NEXT 

IF  NO  EOL  0-> (GPXRB-"80  NEXT  LEAVE  SRTF)  NEXT 

Wl-nD  NEXT  !This  register  transfer  is  pure  machine  dependence. 

IJ0<31 ;  8>-MD<31 :  8>  SL0  1  NEXT  {This  too. 

!U0<31:9>  -  n  -  m  x  2t23. 

U0<7:0>*-0  NEXT 

DECODE  ND<0>«>  {Even  or  odd  exponent 
BEGIN 

0:«(GPXRB*4J0<3l!30>  NEXT  ! I f  even,  shift  argument  two  bits 
U0-U0  SL0  2)  .  Ileft  into  GPXRB. 

!  GPXRB®U0<31:10>-2t1,  Ul-e. 

1:-(GPXRB-U0<31>  NEXT  !If  odd,  shift  argument  one  bit  left 
U0-U0  $L0  1  NEXT  {into  GPXRB  and  add  1  to  exponent. 
EXPOUT-nO<7>@f1O<7:0>  +  1  NEXT  {Exponent  overflow  check. 

141  <7 !  0>-EXPOUT  <7: 0> ) 

!  GPXRBeU0<31il0>  -  M.  Ul-e+1. 

END 

!  In  any  case,  at  this  stage  sqrt CGPXRB®U0<31 : 10>)  x  2t(Ul/2)  equals 
!  2T12  x  sqrt(m)  x  2T(e/2).  So  all  we  have  to  do  is  take  Ul/2  for 
!the  exponent  of  the  answer  and  for  the  mantissa  (in  its  fractional 
•  form)  take  sqrt(GPXRB®U0<31sl0>)  x  2t(-12).  Uhat  is  the  same  ie 
!to  take  sqrt (GPXRB®U0<31: 10>  x  2t22)  x  2t(-23),  in  other  Uords, 

Itake  the  square  root  mentioned  here  as  an  integer,  and  then  just 
! interpret  i t  as  a  fraction  in  the  bits  <30»8>  of  the  register 
.  {containing  the  answer  (bit  <31>  will  be  zero,  since  we  are  finding 

!  the  positive  square  root).  Notice  that  GPXRB<li0>®U0<31 1 10>  x  2t22  Is 
!a  46-bit  number,  and  the  range  of  values  is  >«2t44  and  <-2t46  -  2t22. 


U1<7:0>*-U1<7>®U1<7j1>  NEXT  {Exponent  of  root  is  1/2  previous  value. 
IF  EXP0UT<8>  XOR  EXPOUT<7>->U1<7*0>^100  NEXT 
IThis  is  1/2  of  previous  value 

!in  the  case  of  overflow. 
!So  from  here  to  the  end  we  will  be  finding  the  square  root  of  the 
{integer  GPXRB<ls0>®U0<31:10>  x  2t22. 

{For  proof  of  the  following,  see  <f1ARCUS>SRTFPR00F.X0F. 

COUNTER-0  NEXT 

Ul<31:8>-0  NEXT  {Zero  is  partial  square  root. 

SUn-GPXRB-1  NEXT 
GPXRB-SUf1<29: 8>eU0<31  s  30>  NEXT 


SUBJiHIluilnupiMiWi  « 


SLOOP* 


Ipoaitive  (or  zero)  or  ne g  romalndor 


REPEAT 
BEGIN 

U04J0  SL0  2  NEXT 
COUNTER«-C0UNTER+l  NEXT 
DECODE  SUT1<31>-> 

BEGIN 

0:-  (U1  <31 :  8>«-2*Ul  <31  s  8>  +  1  NEXT 

IF  COUNTER  EQL  23-> (LEAVE  SLOOP)  NEXT 
U2«-4*W1<31*8>  +  1  NEXT 
SUM*-GPXRB-U2  NEXT 
GPXRB*-SUM<29: 0>aU0<31  *  30>) , 

It-  (U1 <31 s 8>-2*Ul <31 1 8>  NEXT 

IF  COUNTER  EQL  23-> (LEAVE  SLOOP)  NEXT 
U2-4*U1<31*8>  ♦  3  NEXT 
SUM-GPXRB+U2  NEXT 
GPXRB*SUM<29  *  0>aU0<31  *  30>) 


ENO 

END 

NEXT 

GPXRB4J1 

ENO. 


VADDFj- 

BEGIN 

AODFO  NEXT 
RA-RA+1  NEXT 
RB-RB+1  NEXT 
MA-flA+l  NEXT 

IF  Af100E«>N0«-f1EM (MAI  NEXT 
AODFO  NEXT 
RA«-RA+1  NEXT 
RB-RB+1  NEXT 
MA*-MA+1  NEXT 

if  AnooE->rio4iEnwA)  next 

AODFO 

ENO, 


IVSUBF  IS  NOT  ON  FLOU  DIAGRAMS 

VttPYF l  • 

BEGIN 

I1PYFO  NEXT 
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RA-RA+1  NEXT 
RB«-RB+1  NEXT 
MA*-MA+1  NEXT 

IF  AMODE->MO-NEM IMA]  NEXT 
MPYFO  NEXT 
RA-RA+1  NEXT 
RB-RB+1  NEXT 
MA-MA+1  NEXT 

IF  AMODE->MD«-MEM [MA]  NEXT 

MPYFO 

END, 

VIPFs- 

BEGIN 

MPYFO  NEXT 
U3*-GPXRB  NEXT 
MA-MA+1  NEXT 
RA-RA+1  NEXT 
RB-RB+1  NEXT 

IF  ANODE  »>MD«-MEM  IMA]  NEXT 

MPYFO  NEXT 

U2-GPXRB  NEXT 

MA.-MA+1  NEXT 

RB-RB+1  NEXT 

RA«-RA+1  NEXT 

OECODE  ANODE -> 

BEGIN 

05-U0-GPXRA, 
OTHERU1SE:  »NO»-MEM  [MA] 

END 

NEXT 

MPYFO  NEXT 
OECODE  AM00E-> 

BEGIN 

0:-GPXRA«-U2, 

1 : -MD-U2 
END 

NEXT 

ADDFO  NEXT 
DECODE  AM0DE-> 

BEGIN 

0«-  (GPXRA442  NEXT 
ADDFO  NEXT 
GPXRA4J0) , 

OTHERUISEj-  (M0-W3  NEXT 
AODFO) 

END 

ENO, 

VSflF  j  - 

BEGIN 

MPYFO  NEXT 
RB-RB+1  NEXT 
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L00P7: 


CFX:  - 


UPFj  - 


L00P8: 


MPYFO  NEXT 
RB-RB+1  NEXT 
MPYFO 
END. 


BEGIN 

REPEAT 

BEGIN 

U1441+2  NEXT 

GPXRB-GPXRB<31 >«GPXRB<31 >«GPXRB<31 i 2>  NEXT 

IF  Ul<7:0>  EQL  0->  LEAVE  L00P7 

END 

END. 


! CONVERTS  GPXRA  OR  MD  IN  FLOATING  TO  GPXRB  INTEGER. 

BEGIN 

CPXRB-MD  NEXT 

IF  GPXRB<7:0>  EQL  0  ->  IEXPONENT-0 

(GPXRB-GPXRB  SL0  1  NEXT 

OF  GPXRB  EQL  0  ->  GPXRB<-1  NEXT  LEAVE  CFX)  NEXT 
OF  GPXRB  NEQ  0  ->  GPXRB-0)  NEXT  LEAVE  CFX)  NEXT 
!  CONVERTS  <X00...0>  TO  -1  AND  A  NON-ZERO  NUMBER  OF  ABSOLUTE 
!  VALUE  <  1  TO  0. 

IF  GPXRB<7>->  IGPXRB-0  NEXT  LEAVE  CFX)  NEXT  INEG  EXPONENT  GOES  TO  0. 
IF  GPXRB<7:0>  NEQ  0  AND  GPXRB<7>  EQL  0  ->  POSITIVE  EXPONENT 
<U1  *-31  NEXT 

U1  *-GPXRB<7 :  0> -U1  <7 :  0>  NEXT 
GPXRB<7t0>*-0  NEXT 
DECODE  Ul<7>®Ul<0>-> 

BEGIN 

0j-  IF  Ul<7:0>  NEQ  0  .>0VFF+1, 

•IF  Ul<7:0>  EQL  0,  JUST  LEAVE  CFX. 
li-  OVFF-1, 

2i-  L00P7O, 

3i-  (Ul 441+1  NEXT 

GPXRB«-GPXRB<31  ><*GPXRB<31 : 1  >  NEXT 
IF  U1  NEQ  0->LOOP7O) 

END) 

END. 


! TAXES  GPXRA  OR  MD  AND  PUTS  THE  EXPONENT  (SIGN  EXTENDED)  AND 
!THE  MANTISSA  IN  SUCCESSIVE  GP  REGISTERS. 

BEGIN 

GPXRB<-MO<7i0>  NEXT 
RB^RB+1  NEXT 

GPXRB<31:8>41D<31:8>  NEXT 

GPXRB<7t0>«.0 

END, 
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BEGIN 

REPEAT 

BEGIN 

DECODE  GPXRB<31s29>-> 

BEGIN 

(0.7] i -  (GPXRB-GPXRB  SL0  2  NEXT 

IF  sunm  XOR  Ul<7>  ->(OVFF-l  NEXT  LEAVE  L00P8)  NEXT 
!  HERE  SUMM1  IS  THE  EXTRA  HARDUARE  BIT  TO  THE  LEFT  OF  THE  EXPONENT 
!  AND  IS  USED  TO  CALCULATE  0VF8  (-SUMM1  XOR  THE  LEFT  MOST  REAL  BIT  OF 
!  EXPONENT.)  ... 

sunm  «141  <7 :  0>-Ul  <7>«U1  <7  s  0>-2 ) . 

!  THE  EXPONENT  PART  OF  U1  IS  ALL  THAT  IS  USED  IN  THE  CONTINUATION. 

(1,61 s-  (IF  sunm  XOR  Ul<7>  -> (OVFF-1  NEXT  LEAVE  LOOPS)  NEXT 
SUMMl®Ul<7s0>-Ul<7>«Ul<7s0>-l  NEXT 
GPXRB-GPXRB  SL0  1  NEXT 

IF  sunm  XOR  Ul<7>  -> (OVFr-1  NEXT  LEAVE  L00P8)  NEXT 
GPXRB<7 :  0>*-Ul  <7 s 0»  NEXT 
LEAVE  L00P8) . 

2s 5s-  (IF  sunm  XOR  Ul<7>  -> (OVFF-l  NEXT  LEAVE  LOOP8)  NEXT 

GPXRB<7 : 0>-Ul <7  s  0>  NEXT 
LEAVE  L00P8) 

END 

END 

ENO. 


PKFj.  STAKES  EXPONENT (GPXRB  OR  nD)  AND  MANTISSA (GPXRA  OR  MEnmAl) 

SAND  PUTS  THEN  TOGETHER  IN  GPXRB  AS  ONE  FLOATING  POINT  NUMBER. 
!  THIS  NEEOS  TO  BE  CHECKED  AGAIN, 

BEGIN 

OECOOE  AnOOE-> 

BEGIN 

0s-  (Ul-GPXRB  NEXT  SEXPONENT 
GPXRB-GPXRA) ,  ! MANTISSA 

OTHERUISEs -  (MA-MA+1  NEXT 

GPXRB-MEM  IMA]  NEXT  (MANTISSA 
Ul-MD)  SEXPONENT 

ENO  NEXT 

IF  GPXRB  EQL  0->  (GPXRB-M80  NEXT  LEAVE  PKF)  NEXT 

LOOP8  0 

END. 


LANOs- 

BEGIN 

GPXRB-MO  ANO  GPXRB 
ENO. 

LXORs • 

BEGIN 

GPXRB-MD  XOR  GPXRB 
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END. 


IOR*. 

BEGIN 

GPXRB-nD  OR  GPXRB 
END. 

ANI:- 

BEG1N 

GPXRB-NOT  MO  ANO  GPXRB 
ENO. 


LOOP1B: « 

BEGIN 

REPEAT 

BEGIN 

no-no+2  NEXT 
OECOOE  GPXRB<29*27>-> 

BEGIN 

10.7] :«  GPXRB-GPXRB  SL0  2. 
OTHERUISE:-  IOVFF-1  NEXT 

GPXRB-GPXRB  SL0  2) 

ENO  NEXT 

IF  f1O<7:0>  EQL  0->LEAVE  LOOP10 
ENO 

END. 


LOOPlli- 

BEGIN 

nD-no+2  NEXT 

IF  GPXRB  EQL  0->  LEAVE  LOOP11  NEXT 
OECOOE  GPXRB<31*29>-> 

BEGIN 

10.73 1.  GPXRB-GPXRB  SL0  2, 
OTHERUISE*-  IOVFF-1  NEXT 

GPXRB-GPXRB  SL0  2) 

ENO  NEXT 

IF  nO<7*0>  NEO  0.>LOOP10() 

ENO. 


LOOPS: - 

BEGIN 

REPEAT 

BEGIN 

MO-nO-2  NEXT 
GPXRB<«GPXRB<31 *  2>  NEXT 
IF  MO<7*0>  EQL  0->LEAVE  L00P9 
ENO 

ENO. 
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J 


ARSs-  ! SHIFTS  GPXRB  THE  NUMBER  AND  DIRECTION  OF  THE  SIGNEO  EXPONENT 
I PART  OF  GPXRA  OR  MO.  RIGHT  SHIFT  CAUSES  SIGN-EXTENSION 
BEGIN 

IF  MD<7:0>  EQL  0->  LEAVE  ARS  NEXT 
DECODE  MD<7>@MO<0>-> 

BEGIN 

0s-  LOOPS  0. 

It-  (MO-MD-l  NEXT 

GPXRB<-GPXRB<31sl>  NEXT 
IF  MO<7:0>  NEQ  0->LOOPSO), 

2s-  LOOPllO, 

3s-  (MO-MO+1  NEXT 

IF  GPXRB  EQL  0->LEAVE  ARS  NEXT 
DECODE  GPXRB<31s29>-> 

BEGIN 

[0, 1,6,7] t>  GPXRB-GPXRB  SL0  1, 

OTHERUISEs-  (OVFF-1  NEXT 

GPXRB-GPXRB  SL8  1) 

END  NEXT 

IF  MQ<7 s 0>  NEQ  0->LOOPllO) 

END 

END. 

LOOP100:- 

BEGIN 

REPEAT 

BEGIN 

MD-MD+2  NEXT 
OECOOE  GPXRB<23:27>-> 

BEGIN 

10,7]  t-  (GPXRB-GPXRB<29s  0>*EX<31 : 30>  NEXT 
EX-EX  SL0  2) , 

OTHERUISEs-  (OVFF-1  NEXT 

GPXRB-GPXRB<29s 0>«EX<31  s 30>  NEXT' 

EX-EX  SL0  2) 

END  NEXT 

IF  MO<7s0>  EQL  0->LEAVE  LOOP100 
END 

ENQ. 

LOOP110S • 

BEGIN 

MO-MO+2  NEXT 
OECOOE  GPXRB<31t29>-> 

BEGIN 

10,7]  i-  (GPXR8«-GPXRB<29s  0>«EX<31  s  30>  NEXT 
EX-EX  SL0  21 , 

OTHERUISEs-  (OVFF-1  NEXT 

GPXRB-GPXRB<29s  0>«EX<31 1 30>  NEXT 
EX-EX  SL0  2) 

ENO  NEXT 
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H ,  jr-  jr 


IF  MO<7:0>  NEQ  0->LOOP100() 

END, 


LOOP90S - 

BEGIN 

REPEAT 

BEGIN 

MO-MO-2  NEXT 
GPXRB<-GPXRB<31s2>  NEXT 
EX-GPXRB<1  j  0>«EX<31 1 2>  NEXT 
IF  f1O<7:0>  EQL  0->LEAVE  LOOP90 
END 

END. 


ARL:.  ’SHIFTS  GPXRBtsEX  THE  NUMBER  AND  DIRECTION  OF  THE  SIGNEO  EXPONENT 
•PART  OF  GPXRA  OR  MO. 

BEGIN 

EX-EX  SL0  1  NEXT 

IF  MD<7:0>  EOL  0->  (EX-EX<31 t 1 >  NEXT  LEAVE  ARL)  NEXT 
DECODE  no<7>®no<0>-> 

BEGIN 

0:-  LOOP90O, 

1:-  (MD-MO-1  NEXT 

EX-GPXRB<0>«GPXRB<31 8 1  >  NEXT 
GPXRB<-GPXRB<31 : 1>  NEXT 
IF  MO<7:0>  NEQ  0->LOOP90 ( ) ) , 

2:-  LOOP110O, 

3:-  (MO-MO+l  NEXT 

IF  GPXRB  EQL  0->IGPXRB-GPXRB<30i0>«EX<31>  NEXT 
EX-EX  SL0  1  NEXT 
(IF  MO  NEQ  0->LOOP110()  NEXT 
LEAVE  ARL)  NEXT 
EX-EX  SR0  1  NEXT 
LEAVE  ARL)  NEXT 


OECOOE  GPXRB<31s23>-> 

BEGIN 

I0,1,G,7] :■  (GPXRB-GPXRB<30j0>*EX<31>  NEXT 
EX-EX  SL0  1), 

OTHERUISE:-  (OVFF-1  NEXT 

GPXRB-GPXRB<30 8  0>«EX<31 >  NEXT 
EX-EX  SL0  1) 

END  NEXT 

IF  MO<780>  NEQ  0->LOOP110O) 

END 

ENO, 


LOOPlZt - 

BEGIN 
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REPEAT 


BEGIN 

MD-MD-2  NEXT 
GPXRB-GPXRB  SRR  2  NEXT 
IF  M0<7 1 0>  EQL  B»  LEAVE  L00P12 
END 

END. 

L00P13: - 

BEGIN 

REPEAT 

BEGIN 

MD-MD+2  NEXT 
GPXRB-GPXRB  SLR  2  NEXT 
IF  hO<7i0>  EQL  B->  LEAVE  L00P13 
ENO 

END. 

RRS:-  ! ROTATES  GPXRB  NUMBER  OF  PLACES  AND  DIRECTIONS  GIVEN 

!BY  THE  EXPONENT  PART  OFGPXRA  OR  MD. 

BEGIN 

IF  MD<7:0>  EQL  0->  LEAVE  RRS  NEXT 
DECODE  MO<7>»MD<0>-> 

BEGIN 

0:-  LOOP120, 

It-  (MD-MO-1  NEXT 

GPXRB-GPXRB  SRR  1  NEXT 
IF  MO<7:0>  NEQ  0->LOOP12() ) , 

2;-  L00P13O, 

3:-  (MD-MO+l  NEXT 

GPXRB-GPXRB  SLR  1  NEXT 
IF  nO<7s0>  NEQ  0->LOOP13O) 

END 

ENO. 


LOOPlAj  m 

BEGIN 

REPEAT 

BEGIN 

MD-MO-2  NEXT 
SUM-GPXRB  NEXT 

GPXRB-EX<1:0>«GPXRB<31j2>  NEXT 
EX-SUM<1 : 0>«EX<31 : 2>  NEXT 
IF  MO<7<0>  EQL  0->LEAVE  L00P14 
ENO 

END. 


L00P15t- 

BEGIN 

REPEAT 


BEGIN 


MO-MD+2  NEXT 
SUM-GPXRB  NEXT 

GPXRB«-GPXRB<29: 0>«EX<31 » 30>  NEXT 
EX«-EX<29: 0>«SUf1<31 : 30>  NEXT 
IF  MO<7:0>  EQL  0->LEAVE  L00P15 
END 

END. 


RRL: -  (ROTATES  GPXRBaEX  THE  NUMBER  OF  PLACES  AND  DIRECTION  OF  THE  SIGNED 
(EXPONENT  PART  OF  GPXRA  OR  MD. 

BEGIN 

IF  MD<7s0>  EOL  0->  LEAVE  RRL  NEXT 
OECOOE  f1O<7>«MO<0>»> 

BEGIN 

0:-  L00P14O , 

1«-  (MD«-MD-1  NEXT 
SUf1*-GPXRB  NEXT 
GPXRB-EX<0>*GPXRB<31:1>  NEXT 
EX*-SUM<0>«EX<31: 1>  NEXT 
IF  MD<7s0>  NEQ  0->LOOP14O), 

2t-  L0DP15O, 

3:-  (MD-MD+l  NEXT 
SUM^GPXRB  NEXT 

GPXRB«-GPXRB<30:  0>«EX<31  >  NEXT 
EX*-EX<30 s  0>«SUf1«31  >  NEXT 
IF  MD<7s0>  NEQ  8->L00P15()) 

END 

END. 


LOOPlGi- 

BEGIN 

REPEAT 

BEGIN 

flO-MO-2  NEXT 
GPXRB^GPXRB  SR0  2  NEXT 
IF  no<7s0>  EQL  0.>LEAVE  L00P16 
END 

ENO. 

LOOP17». 

BEGIN 

REPEAT 

BEGIN 

M041D+2  NEXT 
GPXRB«-GPXRB  SL0  2  NEXT 
IF  MO<7:0>  EQL  0«>LEAVE  L00P17 
ENO 


LRS*  • 


L00P18: 


L00P19: 


LRLs- 


! ZEROS  ARE  SHIFTED  IN. 

BEGIN 

IF  NOT  AMOOE «  >f1D-GPXR  A  NEXT 
IF  nO<7:0>  EQL  8->LEAVE  LRS  NEXT 
DECODE  m<7>*MO<0>-> 

BEGIN 

0s-  LOOP1SO. 

Is-  (MD-MD-1  NEXT 

GPXRB-GPXRB  SR0  1  NEXT 
IF  f1D<7:0>  NEQ  0-»LOOP16O>, 
2s-  L00P17O, 

3s-  (HO-MO+l  NEXT 

GPXRB-GPXRB  SL0  1  NEXT 
IF  f1O<7s0>  NEQ  0->LOOP16O) 
END 

END. 


BEGIN 

REPEAT 

BEGIN 

no-no-2  NEXT 

EX-GPXRB<1  s  0>®EX<31  s  2>  NEXT 
GPXRB-GPXRB  SR0  2  NEXT 
IF  MD<7s0>  EQL  0->  LEAVE  L00P18 
ENO 

ENO. 


BEGIN 

REPEAT 

BEGIN 

nO-MO+2  NEXT 

GPXR8-GPXRB<29:0>«EX<31s30>  NEXT 
EX-EX  SL0  2  NEXT 
IF  MO<7s0>  EQL  0->LEAVE  L00P19 
ENO 

ENO. 


IZERO  IS  SHIFTEO  IN. 

BEGIN 

IF  MO<7:0>  EQL  0->LEAVE  LRL  NEXT 
DECOOE  nO<7>«t1D<0>-> 

BEGIN 

8s-  L00PI8O, 

Is-  IflD-riD-l  NEXT 

EX-GPXRB<0>«EX<31sl>  NEXT 
GPXRB-GPXRB  SR0  1  NEXT 
IF  n0<7s8>  NEQ  8->L00P18() ) , 
2s-  L00P19O, 

3s-  mo-no+l  NEXT 
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GPXRB«-GPXRB<30: 0>«EX<31>  NEXT 
EX*EX  SL0  1  NEXT 
IF  MO<7:0>  NEQ  0»LOOP19O) 
ENO 

END. 


OSIi- 

BEGIN 

DISINT«-1 

END. 

ENI:. 

BEGIN 

OISINT*>0 

ENO. 

RFI:»  'return  from  interrupt 

BEGIN 

PC-MEMIMA]<1S:0>  NEXT 
EXMOOE-MEM [HA] <24>  NEXT 
DISINT^riEnmAJ<23>  NEXT 
DIVFF*-MEM[MA]<22>  NEXT 
OVFF-MEM(MAJ<21>  NEXT 

hiopc41ehcma)<20>  next 

CRYFF«-MEM  II1A]  <19>  NEXT 
1 NTPR I  OR«-I1Ef1  IMA]  <18sl6> 

ENO. 

PET:-  Ireturn  from  subroutine 

BEGIN 

PC*-MEM  IMA]  <15: 0>  NEXT 
DISINT^flEN  ItlA]  <23 >  NEXT 
DI  VFF*-f1EH  (MA]  <22>  NEXT 
0VFF«-f1EM  IMA]  <21  >  NEXT 
ILlOPC-nEM (MA)<20>  NEXT 
CRYFF«-MEM  IMA]  <19> 

END. 


XECt- 

BEGIN 

DECODE  AM0DE-> 

BEGIN 

8i-  1NR-GPXRA, 

OTHERWISE: -  INR«-MEM IMA] 

ENO 

NEXT 

HA<-INR<1S:0>  NEXT 

IF  INRPT->(PC«-PC-1  NEXT  LEAVE  XEC)  NEXT 
ADDRESS!)  NEXT 
OPERAND!)  NEXT 
OPERATION!)  NEXT 
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GPXR {RAJ  -GPXRA  NEXT 
GPXR  (RBI  -GPXRB  NEXT 
INRPT-OVFF  OR  OIVFF 
END 


**Oper a t  i  on.  decode** 


OPERATION: . 
BEGIN 


! opcode  decode. 


DECODE  OPCODE-> 
BEGIN 


!LOAO(FETCHI /STORE 


-LORO. 

-LOEO, 

-LU0O. 

-LU10. 

-LU20. 

-LU30, 

-L0R2O, 

-LDR3  0, 

-L0R7O. 

-LON  ( ) , 

-LDNFO, 

-LDAO, 

•LOAF  ( ) , 

-LDCO. 

•LAO ( ) , 

-LMOO. 

•STRO. 

-STEO, 

-SU0O, 

-sum. 
-SU2U, 
-SU3  0, 
•STOO. 
-STZO, 

-szoo, 

-STR2I), 

-STR3U, 

■STD20 , 

•ST03O, 

•STD7U , 

•STHO, 

•SPSO, 

•SPCO, 

•SBPA10. 

•SBPA0O, 


(LOAD  REGISTER 
ILOAD  EXTENSION  REGISTER 
ILOAO  WORK I NG  REGISTER  0 
ILOAD  UORKING  REGISTER  1 
•LOAD  UORKING  REGISTER  2 
ILOAD  UORKING  REGISTER  3 
•LOAD  MULTIPLE 


ILOAO  NEGATIVE 

ILOAD  NEGATIVE  FLOATING 

ILOAO  ABSOLUTE  VALUE 

ILOAO  ABSOLUTE  VALUE  FLOATING 

ILOAO  ONE'S  COMPLEMENT 

ILOAD  ACTIVE  ONLY 

ILOAD  MONITOR  ONLY 

f STORE  REGISTER 
ISTORE  EXTENSION 
I STORE  UORKING  REGISTER  0 
ISTORE  UORKING  REGISTER  1 
ISTORE  UORKING  REGISTER  2 
ISTORE  UORKING  REGISTER  3 
ISTORE  OOUBLE 
ISTORE  ZERO 
ISTORE  ZERO  DOUBLE 
ISTORE  MULTIPLE  SINGLE 

ISTORE  OOUBLE  MULTIPLE 


ISTORE  TO  HARO  ADDRESS 
ISTORE  PC  AND  STATUS  SINGLE 
ISTORE  PC  AND  STATUS  DOUBLE 
ISTORE  BAD  ADDRESS  PARITY  ONES 
ISTORE  BAD  AOORESS  PARITY  ZEROS 
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! 

i 


4D:-SBPD1(), 
4E: -SBPO0 ( ) , 


! STORE  BAD  DATA  PARITY  ONES 
! STORE  BAD  DATA  PARITY  ZEROS 


IJUMP 


"50: -JMP  ( ) , 
"5E:-JSBO , 
"4F:-JPZO. 
"51S-JMI  0, 
"52:-JZEO. 
"53: -JZEF ( ) , 
"54:-JNZO, 
"55: -JNZF  0 , 
"5G: -JPS ( ) , 
"57:-JPSFO, 
"58:-JMZO, 
"59: -JMZF  ( ) , 
"5A:-JONO , 
"5C: -JOS ( ) , 
"5D:-JCSO, 


!  JUMP 

IJUMP  SUBROUTINE 

IJUMP  IF  POSITIVE  OR  ZERO 

IJUMP  IF  NEGATIVE 

IJUMP  IF  ZERO 

IJUMP  IF  ZERO  FLOATING 

IJUMP  IF  NON-ZERO 

IJUMP  IF  NON-ZERO  FLOATING 

IJUMP  IF  POSITIVE  AND  NON-ZERO  (?) 

IJUMP  IF  POSITIVE  AND  NON-ZERO  FLOATING  (?) 
IJUMP  IF  NEGATIVE  OR  ZERO 

IJUMP  IF  NEGATIVE  OR  ZERO  FLOATING 

I DECREMENT  RB.  JUMP  IF  NON-ZERO 
IJUMP  IF  OVERFLOW  SET.  RESET  OVERFLOU 
IJUMP  IF  CARRYOUT  SET.  RESET  CARRYOUT 


I  TEST  AND  SKIP 


"29:  -OISNO , 
"2D: -01 SO(). 
"2A:-ASNZO. 
"2C:  -ASZO , 
"34: -CSNE  0 , 
"35:-C5EQU , 


I  OR  INVERTED  AND  SKIP  IF  NOT  ONES 
I  OR  INVERTED  AND  SKIP  IF  ONES 
IANO  AND  SKIP  IF  NOT  ZEROS 
I  AND  AND  SKIP  IF  ZEROS 
I  COMPARE  AND  SKIP  IF  NOT  EQUAL 
I  COMPARE  AND  SKIP  IF  EQUAL 


•INTEGER  ARITHMETIC 


"19: -ADD  0. 

"1A: -SUB  0 , 

"IB: -MPY  0 , 

"1C: -01 VI  (), 

"ID: -LOV ( ) , 

"2B:  -ACOO , 

"IE: -CFL ( ) . 

IFLOATING  POINT  ARITHMETIC 


I  INTEGER  ADD 
•INTEGER  SUBTRACT 
I  INTEGER  MULTIPLY 
ISHORT  DIVIDEND  DIVIDE 
I  LONG  DIVIDEND  DIVIDE 
I  ADD  CARRYOUT 

I  CONVERT  INTEGER  TO  FLOATING 


"0C: -ADOF () , 
"CD: -SUBF ( ) , 
"0E: -MPYF  0 , 
"0F: -01 VF () , 
"10: -SRTF  0 , 
"11 : -VADDF  0 , 
"12: -VSUBF  0 , 
"13: -VMPYF () . 
"14;  -VIPFO , 
"15:  -VSMFO , 
"IS:  -CFXO , 


I ADD  FLOATING 
I SUBTRACT  FLOATING 
IMULTIPLY  FLOATING 
IOIVIDE  FLOATING 
I SQUARE  ROOT  FLOATING 
I  VECTOR  ADD  FLOATING 
I  VECTOR  SUBTRACT  FLOATING 
IVECTOR  MULTIPLY  FLOATING 
I  VECTOR  INNER  PRODUCT  FLOATING 
I  VECTOR-SCALAR  MULTIPLY  FLOATING 
I  CONVERT  FLOATING  TO  INTEGER 
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17:-UPF(), 

18:~PKF(). 


(UNPACK  FLOATING 
I  PACK  FLOATING 


‘LOGICAL 


-lFs-LANOO, 

"20:-LXORU  . 
"Zls-IORO, 
"22: -AN!  0, 


•LOGICAL  AND  (Name  changed 
luith  ISPS) 

•EXCLUSIVE  OR  (ditto) 
•INCLUSIVE  OR 
!AND  INVERTED 


•SHIFT/ROTATE 

"23:-ARSO  . 
"24:«ARL<> . 
"2S:-RRS0, 
"2G:-RRL0 . 
"27:-LRSO. 
"28:-LRLO. 


•ARITHMETIC  SHORT  SHIFT 
IAR1THMETIC  LONG  SHIFT 
•ROTATE  SHORT 
•ROTATE  LONG 
! LOG I  CAL  SHORT  SHIFT 
! LOG I  CAL  LONG  SHIFT 


•MISCELLANEOUS 


"50: -OS  I (I , 
"SF:«ENI  0  . 
"60:  -RFI  O, 
"64: -RET  0 , 
"Gl:-XECO 


IOISABLE  INTERRUPTS 
•ENABLE  INTERRUPTS 
•RETURN  FROM  INTERRUPT 
•RETURN  FROM  SUBROUTINE 
j EXECUTE 


END 

END 


rtrtExecut  •  on.  eye  I  e>v* 


CYCLE (MAIN* : - 
BEGIN 

OELAY(I)  NEXT 
PC-1  NEXT 
REPEAT 

BEGIN 

INSTRUCTION!)  NEXT 
ADDRESS!)  NEXT 
OPERAND!)  NEXT 
OPERATION!)  NEXT 
GPXR IRAJ-GPXRA  NEXT 


GPXR[RBJ«-GPXRB  NEXT 
INRPUOVFF  OR  OIVFF 
IF  INRPT->{... 

END 


MISSION 
of 

Rome  Air  Development  Center 

RAVC  pla.»A  and  executes  res  card i,  development,  test  and 
selected  acquisition  programs  In  support  oh  Command,  Control 
Communications  and  Intelligence  (C3I)  activities.  Technical 
and  engineering  support  within  areas  oh  technical  competence 
Is  provided  to  ESV  Program  Ohhlc.es  IPOs)  and  other  ESV 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
veillance  oh  ground  and  aerospace  objects,  intelligence  data 
collection  and.  handling,  inhormation  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


